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(54) Pre-processor for inbound sales order requests with link to a third party available to promise 
(ATP) system 



(57) A method and apparatus for pre-processing 
electronic data requests within an Electronic Data Inter- 
change (EDI) subsystem layer and within an order fulfil- 
ment application system. An order interceptor (201), 
third-party Available To Promise (ATP) interface (204), 
pseudo-sales order workbench (206), and reject 
acknowledgment system processes (207) are provided 
within the order fulfilment application system to accom- 
plish the pre-processing. 

The order interceptor (201) performs an asynchro- 
nous availability check before a sales order is posted. 
The result of the ATP check is stored in an Electronic 
Sales Order (ESO), and is applied during the posting 
process with unique user exits. The result of the ATP 
check is also used to determine key information about 



the sales order, such as the sales organization, and divi- 
sion and distribution channels. The pre-processor uses 
business rules to detemriine if the ESO should be split 
into multiple documents for requests satisfied across 
multiple sales areas. The Workbench (206) provides a 
customer purchase order view of the ESO that looks, 
feels and behaves like actual order entry screens. The 
Workbench (206) also displays messages generated 
from the pre-processor describing why the ESO was 
held for review. After the condition is corrected the 
Workbench (206) re-executes the ESO pre-processor. 
This continues until all messages are corrected or 
marked reviewed. The supplier can decide to either 
accept the request, reject the request or accept individ- 
ual line items. 
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Description 

* 

[0001] The present invention generally relates to pre-processing electronic commerce requests and, more particu- 
larly, to a method and system for modifying electronic commerce requests before they are sent to an order processing 

5 system and to a computer program product for such a method and system. 

[0002] Electronic Data Interchange (EDI) is a fast, inexpensive and safe method of communicating purchase 
orders, invoices, ship notices, test results, and other frequently used business documents between two trading partners 
without human intervention. EDI eliminates paperwork and infomnational delays by allowing two or more computers to 
communicate directly. This is accomplished by having all parties follow an agreed upon EDI data format and communi- 

10 cation standard. 

[0003] Minimum requirements for EDI participation include a computer system such as a PC, mini or mainframe; 
translation software to map internal business transactions to and from EDI standard formats; communication software 
to send and receive EDI files, and support communication protocols; and communication hardware such as a modem 
and a telephone line. 

15 [0004] EDI has three essential components. First, there must be an EDI standard that defines a set of commonly 
agreed upon datafomnat and communication standards. Second, there must be a communications infomiation delivery 
system, which may include telecommunications hardware and software as well as general communication protocols. 
Rnalty, translation software is required, which transfomns data into a format that can be read by an othenvise incompat- 
ible system or networic at either end of a transmission. 

20 [0005] For example, a computer application creates a business transaction (document) which is loaded into a file. 
This file is processed by the EDI translation software where it is mapped into an EDi standard data format. This EDI 
record is then communicated over a telecommunication link to a predetermined business partner. This business or trad- 
ing partner decodes the EDI record by processing it through their EDI translation software, and dumps the infomnation 
into an internal file. This file is then loaded into the trading partners business application. 

25 [0006] As shown in Figure 1 , electronic data requests are sent directly from the customer to the order fulfilment sys- 
tem for processing. Disadvantages of this approach include data replication of master, control, and configuration data 
to the EDI subsystem, and non-integration with the order fulfilment embedded processing rules. Specifically, in prior art 
systems, an EDI order from a customer is received, as shown in function block 101 . In function block 1 02, the EDI order 
is translated into an internal format The Internally fomnatted data is then loaded into the order fulfilment system, as 

30 shown in function block 103. In decision block 104. the order fulfilment system checks for errors, such is incomplete 
fields within the EDI order, or determining if the sender is asking for a product or service that does not exist. If there are 
no errors, the EDI order is processed manually in accordance with business rules of the recipient. For example, if there 
is a request for a specific date and quantity, business rule 1 might be to respond only if the date and quantity requested 
can be satisfied. Rule 2 might be to keep the date, and take whatever quantity that is available. Rule 3 might be to sub- 

35 stitute a different part number for the original part requested if there are not enough of the original parts requested to 
satisfy the order. If the EDI order does contain errors, then, in function block 1 06, the operator must manually correct 
the order. For example, missing fields may be filled in, or information such as a correct customer address may be pro- 
vided. In function block 107, the EDI order is resubmitted, where it is again checked for errors, as shown in function 
block 1 04. Steps 1 04, 1 06 and 1 07 are repeated until decision block 1 04 determines that the EDI order does not contain 

40 any errors. 

[0007] Several patents relate to the pre-processing of presentations, documents, and the like. These pre-process- 
ing systems are not, however, directly applicable to EDI, and have shortcomings with respect to EDI applications. U.S. 
Pat No. 5,577,258 to Cruz et al. discloses an apparatus and method for pre-processing multimedia presentations to be 
delivered to customers such that delays due to interactive response time is virtually eliminated. This method, however, 
45 is not directly applicable to EDI applications.. 

[0008] European Pat No. EP 0 863 678 A2 to Kung discloses a method for automated servk:e provisioning for tel- 
ecommunications companies. Data from a caller is validated to determine whether the caller is an existing customer 
entitled to a requested servbe. Requests are converted into data compatible with the processor of the automated 
method. 

50 [0009] PCT Pat. No. WO 96/20952 to Lucas discloses a central pre-processing system with logistics for documents 
as well as system access based on subscriber identities at the operator of telecommunications system. Document 
related data is pre-processed and stored, and rules for standardized processing of document information are provided. 
U.S. Pat No. 5,594,910 to RIepp et al. discloses a distributed processing, interactive network and method of operation. 
The method discloses a way to provide access to large numbers of applications to a large number of users, and different 

55 methods to streamline the data accesses. U.S. Pat No. 5,752,246 to Rogers et al. discloses a World Wide Web browser 
to fulfill requests from different clients, and a way of requesting, processing and presenting information on the WWW. 
U.S. Pat. No. 5,517,406 to Harris et al. discloses a tool for handling mutual fund related data, where a mutual fund trade 
is priced, extended and trade-acknowledgment is confirmed by a pre-processor. These patents are not, however, 
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directly applicable to EDI, and do not provide the realization of the features or conveniences of an EDI system. 

[0010] The present invention seeks to provide an integrated system and method for pre-processing electronic data 
requests before they are sent to an order processing system. 

[001 1 ] Embodiments of the present invention seek further to provide an interface to a system that provides a plan- 
5 ning and forecast engine that determines rf a material is available for a given quantity and delivery date. 

[0012] Embodiments of the present invention also seek to provide a system and method for making corrections to 
electronic data requests before they are sent to an order processing system. 

[001 3] Additionally, embodiments of the present invention seek to provide a system and method for rejecting elec- 
tronic data requests so that they are not sent to an order processing system when certain criteria specified within the 

10 electronic data request cannot be satisfied. 

[0014] To this end, it is proposed to provide in embodiments of the invention, a computer implemented order inter- 
ceptor that pre-processes Electronic Sales Orders (ESOs), an interface to a third party planning and forecast engine, a 
pseudo-sales order workbench that allows ESOs to be corrected before they are sent to the order processing system, 
and a reject acknowledgment system that rejects ESOs when the ESO contains enters or the ESO cannot be satisfied. 

15 [0015] According to a first aspect of the invention a system is provided for pre-processing orders before they are 
transmitted to an order processing system, comprising: 

an order interceptor receiving and processing electronic sales order data; 

an interface system receiving the electronic sales order data from the order interceptor and performing an avatla- 
20 bility check, wherein the availability check detemriines the portions of the electronic sales order data that can be sat- 
isfied; and 

means for transmitting at least a portion of the etectmnic sales order data to the order processing system. 

[0016] In an embodiment of such a system the order interceptor translates the electronic sales order data to an 
25 internal format of the order interceptor, detemnines if an availability check is required, transmits at least a portion of the 
electronic sales order data, determines if there are any processing problenns associated with the electronic sales order 
data, and processes the electronic sales order data in accordance with business rules^ 

[0017] There is provided, according to a second aspect of the present invention, a computer implemented method 
of processing electronic sales order data before it is transmitted to an order processing system, comprising the steps of: 

30 

receiving electronic sates order data; 

translating the electronic sales order data to an internal format; 

transmitting the electron^ sales order data to an interface system, wherein the interface system performs an avail- 
ability check to determine what portion of the electronk: sales ortler data that can be satisfied; and 
35 rf the availability check indk:ation is to transmit, transmitting the designated portions of the internal fomnat data to 
the order processing system. 

[0018] Preferably the electronk: sales order data in the system or method is in a standard Electronic Data Inter- 
change (EDI) format. 
40 [0019] Advantageously the system is a SAP system. 

According to a third aspect of the present invention computer program product is provided comprising: 

a computer usable medium having computer readable program code embodied in the medium for pre-processing 
orders before they are transmitted to an order processing system, the computer program product having: 
45 first computer program code for receiving electronic sales order data; 

second computer program code for translating the electronic sales order data to an internal format; 
third computer program code for transmitting the electronic sales order data to an interface system, wherein the 
interface system performs an availabil'rty check to determine the portions of the order interceptor data that can be 
satisfied; and 

50 fourth computer program code for determining if the availability check indication is to transmit at least a portion of 
the order interceptor data to the order processing system, and, if so, transmitting the designated portions of the 
electronic sales order data to the order processing system. 

[0020] Accordingly, in the prefen'ed embodiment of the invention, a supplier enabled for electronic commerce using 
55 the SAP AG Corporation sales and distribution modules for order fulfilment can use the Electronic Sales Order (ESO) 
pre-processor (e.g. the order interceptor) to perfonn an asynchronous availability check (using, for example, the 
PROFIT Available to Promise (ATP) by International Business Machine Corp., or any other suitable third party software 
package) before the sales order is posted to the order processing system. The ATR system is the planning and forecast 
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engine that determines rf a material is available for a given quantity and delivery date. The result of the ATP check is 
stored in the ESO and is later applied to the order processing system. The order Interceptor derives the prerequisite 
data for the ATP check by supplementing the ESO with SAP master and configuration data. The result of the ATP check 
is also used to detenmine key information about the sales order, such as the sales organization, and division and distri- 
5 bution channels (sales area). 

[0021] In the prefen'ed embodiment, the ESO pre-processor spirts the ESO into multiple requests if there are mul- 
tiple line itenns supplied by different delivery plants that are not configured to share the same sales area in SAP. Without 
this function, the supplier would have to perfomri this activity manually. 

[0022] In addition to supporting a third party availability check and subsequent splitting of the ESO, the pre-proces- 
10 sor provides a robust set of business rules that allows a supplier to configure how a request is managed. These busi- 
ness rules allow certain functions to be automated if specified criteria are satisfied. For example, a new sales order 
request from a low-tiered customer can be configured for manual service prior to posting. The same request from a 
high-tiered customer can be configured for manual review only under certain conditions, such as if the requestor falls 
under minimum order quantity levels, while the same request from another customer in the same condition could be 
15 configured for automatic routing. 

[0023] In the preferred embodiment, ESOs held for review can be viewed and edited by using the Workbench com- 
ponent of the pre-processor. The Workbench replaces the generic tool supplied by SAP AG Corporation. The Work- 
bench provides a customer purchase order view of the ESO that looks, feels and behaves like actual order entry 
screens. In addition to displaying the ESO, the Workbench displays messages generated from the pre-processor 
20 describing why the ESO was held for review. When a message is executed, the Workbench branches to the appropriate 
data correction screen. The branch could be to a specific segment in the ESO, to master data, or to configuration data. 
After the condition is corrected, the Workbench re-executes the ESO pre-processor. This continues until all messages 
are con-ected or marked reviewed. The supplier can decide to either accept the request, reject the request, or accept 
individual line items. 

25 [0024] Finally, in the preferred embodiment, if the request is rejected, then an auto reject acknowledgment is gen- 
erated without posting the ESO to the order processing system. If the request is accepted, then the ESO is routed to 
vendor supplied function modules for sales order posting the ESO to the order processing system. Partial accepts are 
communicated back to the customer through the outbound acknowledgment process. 

[0025] There are several features of the order interceptor of the present invention that distinguish it from other pre- 
30 processors of this kind. Rrst, the order interceptor is implemented inside of SAP's table space after the ESO is created 
by SAP's IDOC/ALE application layer (see Figure 6, 600, 601, 602, 604 and 608) and before sales order posting. All 
other pre-processors of this kind are implemented outside of SAP's IDOC/ALE application layer, typically on fiat files 
that are in ESO format. With this approach, all tracking, logging and other capabilities inherent in SAP's IDOC/ALE 
application layer are lost. The order interceptor of the present invention is thus capable of adding, changing, and delet- 
es ing ESO data segments. The hierarchy of the ESO data segments are redetermined each tirfie changes are applied to 
the ESO. All changes to the ESO are logged in the ESO status segments, thus providing a full audit ti^il of activity. The 
program that rebuilds the ESO Is packaged individually and can be used by other pre-processors that have the need to 
manipulate the ESO in this manner. 

[0026] Another feature of the present invention is that the order interceptor supports an asynchronous interface to 
40 a third party ATP System running on a remote server. The result of the availability check is stored in uniquely configured 
ESO data segments and applied to the sales order during posting. Before initiating the availability check, the ESO order 
interceptor analyzes the ESO to see if ATP commits are present If found, the availability check is bypassed and the 
sales order is posted with the ATP commits already on the ESO. In addition, the ESO can be split into multiple ESOs 
based upon the results of the ATP check. The business rules for when to split the ESO is implemented separately from 
45 how the ESO is split 

[0027] A third feature is that the order interceptor performs various edits and audits based upon business rules con- 
figured by customer, logical message type and message code. For example, one of the unique features of the present 
invention is to configure the system to hold the ESO for manual review when a predefined condition arises before post- 
ing to the application. This gives the supplier the opportunity to perfomi error detection and con-ection above those sup- 
so plied by SAP AG Corporation. The ESO order interceptor also provides various user exits for customer specific 
requirements using the SAP Corporation SMOD and CMOD ti-ansactions. The SMOD and CMOD transactions allow 
enhancements to be made to the base functionality of the software. For example, additional processing steps can be 
added to the base functionality of the software. After the additional processing steps, the processing associated with 
the base functionality resumes. 
55 [0028] Further, the workt)ench component of the order interceptor provides the supplier with a tool to change the 
ESO and perfomri any necessary en-or con-eclion identified by the order interceptor. This workbench replaces a generic 
tool supplied by SAP. The workbench provides a unique view of the ESO so that the user does not have to know the 
structure and qualifiers of the ESO. The screens are presented in pre-sales order format thus giving them a preview of 
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the 'to be* sales order. In addition, the workbench provides branches to various SAP AG Corp. master and configura- 
tion data tor en^or correction and analysis, as well as a branch to the generic tool supplied by SAP AG Corp. for ESO 
editing. Another unique feature of the workbench is the auto-reject function. The supplier can reject a request and gen- 
erate an acknowledgement without posting to the application, all within the vendor's IDOC/ALE layer. 

[0029] For a better understanding of the present invention reference will now be made, by way of example, to the 
accompanying drawings, in which: 

Figure 1 is a flowchart illustrating how EDI orders are processed in accordance with conventional methods; 
Figure 2 is a block diagram showing a preferred embodiment of order interceptor system components; 
Figure 3 is a flowchart illustrating the overall process of pre-processing orders before they are posted to the order 
processing system according to the present invention; 

Figure 4 is a flowchart illustrating the process of the pseudo-sales order workbench; 
Rgure 5 is a flowchart of the reject acknowledgment process; 

Rgure 6 is a block diagram showing a preferred embodiment of the relationship of the software modules that com- 
prise the order information processing system; 

Rgure 7 shows a preferred embodiment of a pre-sales overview menu screen displayed from the pseudo-sales 
order workbench; and 

Rgure 8 shows a prefen'ed embodiment of a pre-sales order delivery schedules screen displayed from the pseudo- 
sales order workbench. 

[0030] With reference now to the drawings, and more specifically to Figure 2, the order interceptor system which 
embodies the principles of the invention is shown. The order interceptor system includes an order interceptor 201 for 
pre-processing ESOs before they are posted to the order processing system 209. The order interceptor 201 includes a 
translator 202 for translating a customer's order data into an internal format. The order data is received via a standard 
EDI fomnat transmission 203. After translating the customer's order data into an internal format, the order interceptor 
201 begins to process the data by customer specific business rules contained in the business rules database 21 0. For 
example, a new sales order request from a low-tiered customer can be configured for manual service prior to posting. 
The same request from a high-tiered customer can be configured for manual review only under certain conditions, such 
as if the requestor falls under minimum order quantity levels, while the same request from another customer in the same 
condition could be configured for automatic routing. If the order interceptor 201 determines that an ATP check is 
needed, the order interceptor 201 will interface with ATP system 204 to collect the needed data from the data translator 
205. The ATP system 204 serves as a planning and forecast engine that determines if a material is available for a given 
quantity and delivery date. 

[0031] If the order interceptor 201 determines that any of the business rules contained in the business rules data- 
base 21 0 fail, or there are any other processing problems, the order interceptor 201 interfaces with a sales order work- 
bench 206, which allows corrections to be made. The pseudo-sales order workbench 206 allows for manual review, 
modification, and/or corrections to the customer's order data within the internal format. The customer's order data is 
presented in a fomnat as if the end user is processing an order online within the order processing system 209. The 
pseudo-sales order workbench 206 allows for field modifications as well as functions such as rejecting a customer's 
order. 

[0032] If processing calls for the order to be rejected, the order interceptor 201 interfaces with the reject acknowl- 
edgment system 207 to perfomn that reject so that the ESO request is not processed by the order processing system 
209. The reject acknowledgment system 207 takes the customer's order data in an intemal format and creates an 
acknowledgment containing reject codes that indicate why a customer's order has been rejected. For example, one rea- 
son an order may be rejected is that there is not enough inventory on hand to satisfy the customer's order, and appro- 
priate customer values. The reject codes are then transmitted back to the customer in a format the customer can 
understand so that the customer knows why the order has been rejected. The reject acknowledgment system can also 
reject any changes that are made to existing orders. Further, the reject acknowledgment system can also be used to 
reject customer forecast requests. For example, a customer may query if a certain quantity of parts can be provided, 
say, in 4-6 months. The reject acknowledgment system 207 again creates the reject codes, and then transmits them 
back to the customer in a fomnat the customer can understand so that the customer knows why the forecast has been 
rejected. 

[0033] After the order interceptor 201 has pre-processed the customer's data, as described above, a router 208 
routes the data to the designated order processing system 209, such as the IBM Corporation's OEMLS order process- 
ing system 21 1 or the SAP AG Corp. order processing system 21 2, by interpreting the customer specific configuration. 
For example, if a customer has a request for parts to be delivered on his dock as the request date, this can be called 
the dock date. A ship date may be defined as when a customer wants the parts shipped from a supplier. Another con- 
figuration may be based on transit time, which can be factored in to the order so that the customer will receive the order 
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on or before the date requested. 

[0034] Preferably, the present invention uses IBM RS60bo engines running under a common umbrella, utilizing the 
AIX operating system (the IBM Corp. version of the UNIX operating system), and connected with a high speed comput- 
ers, such as stand alone UNIX or Windows NT work stations, or workstations in a network. Mainframes, including IBM 

5 AS400 and ES9000 computers, may also be utilized. In Rgure 3, the major steps involved in the pre-processing of an 
incoming sales order are shown. The process starts when the order Interceptor translator 202 receives a standard EDI 
transmission 203. Upon receipt, the translator 202 translates the EDI transmission 203 data into an internal fonnat, as 
shown in function block 304. Fields such as sales area and delivering plant are derived and added back to the inbound 
ESO, and fields such as order quantity and ship date may be altered. 

10 [0035] In function block 305, the order interceptor 202 processes the data contained within the EDI transmission 
203. During processing, the order interceptor 201 determines if an ATP check is needed, as shown in decision block 
306. The ATP system, shown in function block 204 is the planning and forecast engine that determines if a material is 
available for a given quantity and delivery date. If the result of the test performed in decision block 306 indicates that an 
ATP check is required, the order interceptor 201 interfaces with the ATP system 204. In decision block 308, the ATP sys- 

15 tem 204 tests to detemnine if the ESO data needs to be translated into an internal format. If yes, the ESO is translated 
by the data translator 205, as shown in function block 307. After data is added in function block 307, or if the test in deci- 
sion block 306 indicates that ATP processing is not required, or if the test in decision block 308 indrcates that data does 
not need to be added, a test is then made in decision block 309 to determine if there are any other processing problenns, 
or if any of the business rules 210 have failed. 

20 [0036] If rt is detennined in decision block 309 that the ESO does not satisfy all of the applicable business rules 21 0, 
or if the ESO is incomplete, in error, or requires manual review, then the order interceptor 201 creates a workflow item 
that can be executed from the in-basket of a responsible person so the workflow item can be reviewed and modified by 
using the pseudo-sales order workt}ench 206, as shown in function block 31 0. 

[0037] Within the pseudo-sales order workbench 206, a test is made in decision block 31 1 to determine if the ESO 
25 has been rejected. The pseudo-sales order workbench 206 allows for manual review, modification, and/or corrections 
to customer order data within an internal format. The customer's order data is presented in a fonnat as if the end user 
is processing an order online within the order processing system 209. It allows for field modifications as welt as func- 
tions such as rejecting a customer's order. If the ESO is rejected, then an acknowledgment is generated back to the 
customer without posting the ESO to the order processing system 209, as shown in function block 312. If the ESO is 
30 not rejected by pseudo-sales order workbench 206, then the ESO is transmitted to the order processing system 209 
and posted to the application, as shown in function block 313. After the appropriate action in function block 312 or 313, 
the process stops, as shown in temnination block 314. 

[0038] Rgure 4 shows a functional flow diagram of the pseudo-sales order workbench 206. When ESO errors are 
encountered, workflow items are created by the SAP Workflow, as indk:ated in function block 402. The workflow Items 

35 are sent to the in-basket of the responsible person. When the work item is executed, as shown in function block 401 , 
the work flow is displayed on a user terminal, as indicated by step 407. ESOs can also be displayed from the SAP work- 
flow 402 that satisfy selection criteria that a user inputs into display block 403. Work flow messages are created under 
pre-defined conditions and routed to the responsible person for action. The responsible person can view and execute 
their messages from their SAP Office Inbox (not shown). When the message is executed, the user is branched to the 

40 appropriate application to correct the condition. In a prefen^d embodiment of the present invention, a workflow mes- 
sage is created when the order Interceptor 201 encounters an en^or or determines that a manual review of the ESO is 
required. The user can also input selection criteria via the an input screen, as shown in step 403, to display ESOs that 
satisfy the selection criteria, as shown in function block 401 . The ESOs are stored in accordance with the SAP AG Corp. 
ESO tables ESO control 404, ESO Data 405, and ESO Status 406. These tables validate the ESO structure, and pass 

45 control to ALE where the ESO can be processed into the appropriate business object, such as a sales order or a pur- 
chase order acknowledgment, etc. The en'or message table 415 displays the error messages, as shown in function 
block 408. Once the en^r messages have been displayed, the user can also view the fields 409 associated with the 
ESOs on the pseudo-sales order workbench 206, as shown in function block 409. The user can also perfonm various 
operations on the ESO, as indicated in function block 410. A test is then made in decision block 41 1 to detemnine if the 

so ESO complies with the configuration rules and updates. If the ESO does not satisfy the configuration rules, a message 
is sent to the Pseudo-sales order Workbench, as shown in function block 41 2. If the ESO satisfies all configuration rules 
and updates, then the ESO is updated in tables 404, 405, 406 and 415. The process returns, as shown in function block 
414. If the user specified selection criteria via display 403, then the return is to the user's display temriinal 403. If the 
SAP workflow 402 created the work item, then the retum is back to SAP workflow 402. 

55 [0039] Rgure 5 is a flow diagram of the Reject Acknowledgment System 207. The reject acknowledgment process 
takes an ESO that was rejected in the order interceptor 201 and creates a con-esponding outbound ESO containing the 
reject codes and appropriate values. The reject acknowledgment process can be used to reject incoming ESOs with 
types sales orders, sales order changes, or forecasts. An inbound ESO with one of these types can be rejected from 
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the order interceptor 201 by entering a reject code for the ESO. As shown in function block 501 , the rejected inbound 
ESO is read from the tables 404, 405, and 406. In decision block 505, the ESO is analysed to determine rf tt was a web 
order. If yes, the ESO is closed/and no acknowledgment is sent, as indicated in function block 406. If decision block 
505 detennines that the order is not from the web, customer configuration table 508 is read to determine the customer . 

5 configuration for responses. In decision block 507, a determination is made whether the customer has requested the 
acknowledgment to contain the values of the SAP order book, or the original values that the customer sent in for the 
ESO. If the customer has requested to have the original ESO values sent in the acknowledgment, the original values 
that the customer sent in for the ESO are read and used, as indicated in function block 509. If the customer has 
requested that the values from the SAP order book be sent in the acknowledgment, the SAP order tables 51 1 are read 

10 and these values are used, as indicated in function block 510. Once the appropriate data is obtained for the acknowl- 
edgment from either function block 509 or 510, the outbound ESO acknowledgment is created in block 512 using the 
reject codes from the rejected ESO, and the ESO configuration table 513 is updated with the acknowledgment ESO 
number. The reject acknowledgment system allows the response to the customer with the reason it was rejected with- 
out sending the customer's order request to the order processing system 209. 

15 [0040] The following is a description of a preferred embodiment of the software modules used to implement the 
claimed invention. It will be apparent to those skilled in the art that the individual software modules could be designed 
and arranged so that they may individually provide different functionality, while the overall combination of sofhA^re mod- 
ules maintains the functionality recited in the claims. 

[0041] A block diagram of how the software modules interface with each other is provided in Figure 6. In general, 
20 inbound sales order requests that are to be fulfilled in SAP are routed as a flat file to the operating system where SAP 
is installed. The flat file representing the ESO is in SAP's published ORDERS02 ESO format for both new and change 
order requests and DELFOR01 for scheduling agreement forecasts and just in time deliveries. OR0ERS02 and 
DELFOR01 fomriats consist of various data segments comprising the ESO. Example data segments in ORDERS02 are: 
E1EDK01 (header general data), E1EDK14 (header organization data), E1EDP01 (item general data), and E1EDP20 
25 (item schedule lines). Example data segments In DELFOR01 are: El EDK09 (header data for JIT suppliers), El EDP1 0 
(item data for JIT suppliers), and El EDP16 (item schedules for JIT suppliers. Typically, these requests originate from 
EDI, but they can originate from any external interface. The ESOs are a derivative of SAP's ESO ORDERS02 format 
for new and change orders and DELFOR01 for scheduling agreement forecast and Just In Time (JIT) releases. 
[0042] The EDLDATA_INCOMING module 601 is a standard SAP function module that initiates the processing of 
30 the flat file representing the ESO. The EDLDATAJNCOMING module 601 calls the RSEINBOO module 602, passing 
the ESOs to be processed. 

[0043] The RSEINBOO module 602 is the SAP Corp. standard program to process inbound ESOs irespective of 
the application. Its main purpose is to load the file representation of an ESO into SAP ESO tables 404, 405 and 406, 
validate the ESO structure, and pass control to ALE where the ESO can be processed into the appropriate business 

35 object, such as a sales order or a purchase order acknowledgment, etc. If errors occur during the process, the 
RSEINBOO module 602 creates a workflow item which can be processed by an administrator using the standard ESO 
workbench nrtodule 608. ALE provides robust configuration support in detemnining how and when the ESO is proc- 
essed- For inbound sales order requests, all customers will be configured to be routed through the pre-processor, 
Z_IDOC_INPUT_PRE_PROCESS module 603. This module is the first in a series of locally developed modules that 

40 perfomn the pre-and post-processing of an ESO prior to posting as a sales order. This processing supplements the SAP 
supplied function modules IDOGJNPUT_ORDERS/ORDCHG/DELINS (not shown) by manipulating the ESO before 
SAP's processes are called. 

[0044] After the RSEINBOO module 602 validates and creates the ESO, control is passed to the IDOC_INPUT mod- 
ule 604, whrch is inside SAP's IDOC/ALE layer. Modules 600, 601, 602, 604 and 608 comprise the IDOG/ALE layer. 
45 Here, configuration tables are analyzed to determine how to process the inbound ESO. Again, for inbound sales order 
request, ALE will pass initial control to the pre-processor function module Z_IDOG_INPUT_PRE_PROGESS module 
603 for local processing. 

[0045] When ESO enrors are encountered by the RSEINBOO module 602, workflow itenns are created by the work- 
flow module 605 and sent to the in-basket of a responsible person. When the work item is executed, the IDOC Work- 
so bench module 606 generates a display on a user terminal. The EDI administrator can view the status of the ESO along 
with error text to detemriine the cause of error. The administrator can correct individual data segments of the ESO and 
initiate reprocessing of the ESO. The IDOG workbench module 606 enables an EDI administrator to manage raw data, 
but is not intended for a sales order entry person. One would have to know the relationship of the ESO segments as 
well as understand code qualifiers. For example, data segment El EDPI9, qualifier '001' represents customer material 
55 and qualifier '002' represents internal material. The IDOG Wori<bench module 606 is only intended to correct data errors 
that local processing does not handle. For example, a segment hierarchy error is detected before the pre-processor is 
called. All application related errors, such as duplicate PO number, will be handled in customer purchase order work- 
bench module 607. 
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[0046] When work items related to IDOC workbench module 606 are executed, the IDOC_MANUAL_INPUT mod- 
ule 608 is called. This function module passes control to the IDOC workbench module 606 and awaits to process the 
results. If the retum code Indicates the ESO is to be processed, control is passed to the IDOC_INPUT module 604, and 
the appropriate application is called via ALE. If the ESO is processed successfully by the application, then the 
5 IDOC_MANLIAL_INPUT module 608 updates the status of the work item to complete, indicating that it can be removed 
from the in-basket If no action is taken from the IDOC Workbench module 606, the work item remains in the in-basket 
in an in-process status. If an error occurs during the application process, then the current work item is marked complete 
and a new work item is created in a ready status and displayed In the in-basket. This process is also used to model the 
Z_ IDOC_MANUALJNPUT module 609 and the Z_ IDOCJNPUT module 610 used with local processing. 

10 [0047] It should be noted that the following numbers correspond to the following activities cited hereafter in the 
specification: 

850 - New Sales Orders 
855 - Acknowledgment to sales order 
75 860 - Change Order 

865 - Acknowledgment to change order 

830 - Forecast 

870 - Response to Forecast 

so ZO- ESO Held for Order interceptor 

Z1- ESO in Pre-Process Status 

72- ESO Held for Pseudo-sales order Workbench 

Z3- ESO Rejected in Pre-Processing 

Z4- ESO in Pre-ATP status 
25 Z6- ESO Closed Without Posting to Application 

Z7- ESO Closed Wrthout Posting and Routed to OEMLS 



[0048] For all inbound sales order requests, the I DOC/ALE layer will be configured to pass control to the local 
Z_IDOCJNPUT_PRE_PROCESS module 603. For now, the pre-processor module 603 will support requests using 
30 ORDERS02 and DELINS ESO format. Cun*ently, this includes 850/862 new order requests, 860 change order requests 
and 830/E forecast and JIT scheduling releases. 850 also includes create contract and create with reference to a con- 
tract. 

[0049] The ZJDOC_INPUT_PRE_PROCESS module 603 is where local pre-order processing occurs that is not 
supported by standard SAP. The data in the ESO is audited above standard SAP edits and audits. In addition, conver- 
35 sions unique to particular users will be performed. Relds such as sales area and delivering plant are derived and added 
back to the inbound ESO. Relds such as order quantity and ship date may be altered based upon local business rules 
such as, for example: (i) round the order quarrtity up to the minimum order quantity defined in the materials sales view, 
or (ii) offset the request date with the transit time. All these conversions occur prior to the request being routed to the 
PROFIT/ATP module 618. 

40 [0050] If the ESO is incomplete, in en^or, or requires manual review, then the Z_IDOC_INPUT_PRE_PROCESS 
module 603 creates a workflow item 605 that can be executed from the in-basket of the responsible person to review 
and modify the request by using the customer purchase order workbench 607. If the ESO is rejected, then an acknowl- 
edgnient is generated back to the customer without posting the document to the application. The ESO's status is set to 
Z3. If the ESO is marked complete, then the ESO's status is set to Z6 and not posted to the application. Likewise, if the 

45 ESO is rerouted to OEMLS (21 1 ), then the ESO's status is set to Z7 and not posted to the application. Othen/vise, if the 
ESO is complete and accepted by the User, the request is first routed to module 613 if one or more materials on the 
ESO is on the PROFIT/ATP module 61 8, and then to the post-ATP module 616 to post the document 
[0051] The User can access ESOs held by the pre-processor 603 by executing work items in their Office inbox or 
by using the "Analyzer" drill-down report module 61 1 (trx ZEDU). This module provides a front-end to the inbox process 

50 that allows search parameters, such as delivery plant document type, and ESO status and displays the ESOs in report 
format with drill-down and mass processing capabilities. From the list, the User can branch to customer purchase order 
workbench module 607, existing sales order transactions, or to the native IDOC workbench module 606. The report 
gives a visual representation of the ESO's status by using traffic light icons and can display why the ESO was held by 
. the pre-processor module 603. This can help the user prioritize which ESOs to process first and so on. In addition, the 

55 report can also be used to compare data on the ESO to data on the existing sales order for change type of requests. 
[0052] If pre-processor module 603 detects an en^or or manual review condition, the woricflow module 605 creates 
a workflow that is made available to the in-basket of the responsible person. Once the work item is executed, the cus- 
tomer purchase order workbench module 607 is provides a display to a user terminal. The user interface is modeled 
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after the incompletion log for processing sales orders. The initial screen wilt display a list of messages identifying why 
the request was held along with key information from the ESO's control and data record segments. If the user is author- 
ized, each item in the list can be executed and taken to the appropriate screen to correct or review the data. After each 
con-ection, the ESO is reprocessed by pre-processor module 603. After executing the message, control goes back to 

5 the main screen. Messages will be removed from the list if it now passes all the edits and audits for that rule. If the 
request was held for manual review, the User can navigate to an overview screen to review the request using screens 
similar to those in SAP sales order process. There, certain fields can be updated, such as sales area and delivery plant. 
Some fields however, can only be changed in conjunction with executing specific messages. For example, the cus- 
tomer's PO number can be changed only if a duplicate error is detected. For 860 change order requests, the con^e- 

10 spending sales order information can be displayed to assist the user in analysis by drilling down on the order number 
field. Additionally, a branch to the native SAP IDOC Workbench can be made by drilling down on the ESO number, as 
provided by the analyzer drill down report module 61 1 . Access is now available to all ESO segments and data that may 
not have been available in customer purchase order workbench module 607. 

[0053] To reject all or part of the request, the user must provide a reject reason code at either the header or line 

15 level. A configuration table will be checked by customer and transaction code to see if partial rejects are allowed. If all 
line items are rejected, or the header is rejected, then an 855/865 acknowledgment is generated once the request is 
released from the customer PO workbench module 607. In this case, the request Is never posted to the sales order sys- 
tem. For 850 new orders, if any of the line items are accepted, then the entire order is loaded into SAP with rejected line 
itenns flagged as rejected with the appropriate reason code. The acknowledgment will be sent as part of the sales order 

20 post process. For 860 change orders, only the line items accepted are passed to the SAP sales order process. All 
rejected line items along with their reject codes are stored for subsequent processing. After the sales order change is 
posted, the acknowledgment process will pick up those lines rejected in workbench module 606 and merge them along 
with the accepted line items on the sales order and create one acknowledgment for the order. Once the user releases 
the request the order is routed back to pre-processor module 603, and if no en^or or review conditions are detected, the 

25 request routed to ATP module 61 8, and finally to the SAP supplied function modules 616 and 61 7 to post the order. 
[0054] If the user rejects the customer's request in the customer purchase order workbench module 607, then the 
appropriate outbound ESO acknowledgment (855/865/870) is generated automatically by the Z_ACK_REJ_CUST_PO 
module 612. The ESO can be rejected at either the header level or t)y rejecting all line items on the ESO. Rejected 
ESOs never get posted to the sales order application. The ESO's status is set to Z3. Module 61 2 supports two methods 

30 of acknowledging rejects back to the customer based upon customer configuration table 508. If the value is 'A' or blank, 
then the acknowledgment is built from the original ESO with the appropriate reject code. If the value is 'C, for new order 
requests, the acknowledgment is built from the original ESO without a reject code. For change order requests, the 
acknowledgment is built using the existing sales order without a reject code. 

[0055] When work items related to the customer purchase order workbench are executed, the 
35 ZJDOC_MANUALJNPUT module 609 is called. This module passes control to the customer purchase order work- 
bench module 607, and awaits to process the results. If the return code indbates the ESO is to be processed, control 
is passed to the ZJDOCJNPUT module 610 whk;h calls the pre-processor in this case. If the ESO is processed suc- 
cessfully by the application, then the Z_IDOG_MANU/VL_INPUT module 609 updates the status of the work item to 
complete indbating that it can be removed from the in-basket If no action is taken from the customer purchase order 
40 workbench module 607, the work item remains in the in-basket in an in-process status. If an error occurs during the 
application process, then the current work item is marked complete and a new work item is created in a ready status 
and displayed In the in-basket. 

[0056] After the inbound request has successfully cleared the Z_lDOCJNPUT_PRE_PROCESS module 603 and 
customer PO workbench module 607. and if one or materials on the ESO is on the PROFIT/ATP module 618, the 

45 ZJDOC_INPUT_PRE_ATP module 613 is called. Here, the PROFIT/ATP interface file ZATPDEM is used as the com- 
muncation vehicle between SAP and the third party ATP system. For example, for IBM Corp., the third party ATP sys- 
tem is PROFIT/ATP. The file is managed by PROFIT/ATP module 618. The rules for managing entries in the 
PROFIT/ATP interface file are the same rules used in the SAPMV45A module 617. The "save document" user exit was 
changed to apply the PROFIT/ATP results to the sales order. For requests already committed by the PROFIT/ATP mod- 

50 ule 618 (requests from 9BD), a dummy reservation is created to bypass the PROFIT/ATP module 618. In this case, the 
request is considered complete by the PROFIT/ATP module 61 8 and no response back is required. In this case, control 
returns back to pre-processor module 603, which directly initiates post-atp processing 615. Requests requiring 
PROFIT/ATP module 618 action are added to the interface table and are sent to the PROFIT/ATP module 618. If the 
link is active and responding in a timely fashion, then control returns back to pre-processor module 603 which directly 

55 initiates post-atp processing at module 615. If the link is not responding, then pre-processor module 603 reinitiates 
module 613 in a mode to indicate that the response is no longer synchronous and to trigger the ZMOM103 module 61 9 
after responding. The restart ESOs in Z4 status (ZMOMI03) module 61 9 restarts the ESO process at the post-atp step. 
[0057] The module Z_FORMAT_ATP_DATA (not shown) is used to encapsulate the interface from SAP to PROFIT. 
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The module interfaces entries in table ZATPDEM to the PROFIT/ATP module 618 via module 
2_PROFIT_DATA_EXTRACT (not shown). 

[0058] The module Z_PROFIT_DATA_EXTRACT (not shown) is a remote function used to pass reservation request 
from SAP to the PROFIT/ATP module 618. The use of MQSeries is transparent to the application. 

5 [0059] The PROFIT/ATP module 61 8 services the request made by the Z_PROFIT_DATA_EXTRACT module (not 
shown). The PROFIT/ATP module 618 communicates its response by calling remote function call 
Z_PROFIT_DATA_LOAD (not shown). Module Z_PROFIT_DATA_LOAD (not shown) is called remotely from the 
PROFIT/ATP module 61 8 to update commit data for reservations in table ZATPDEM. This table is then used to commu- 
nicate the commit data to SAP sales order processes. After the interface table is are updated, event 

10 2_EDI_ATP_START (not shown) is started if the request to PROFIT/ATP module 61 8 can not be performed in a syn- 
chronous mode, such as when the link is down or slow in responding. This event starts ZMOMI03 61 9 which restarts 
the process. 

[0060] If the Z_IDOC_INPUT_PRE_PROCESS module 603 determines that a previous request for a customer and 
given purchase order is pending an acknowledgment, then the inbound ESO's status will be set to 'Queued for Pre- 

15 Processor* (ZO). The definition of incomplete In this case means that a prior ESQ has not been posted by the sales 
order application or the original sales order is incomplete or blocked for any reason. This feature can be disabled by 
changing the corresponding column in table 508 using trx ZEDI. The ZMOM101 module 614 will be scheduled as a 
reoccumng job run houriy to process ESOs are in this status. Each request will be checked for pending acknowledg- 
ments. If the request is cleared for process, then control is passed to the Z_IDOCJNPUT module 610 which calls the 

20 pre-processor and manages the ESO's status and work item; otherwise, the request is held until the next run of the 
ZMOM101 module 614. 

[0061] If one or more materials contained in the ESO are on the PROFIT/ATP module 618, then the ESO must be 
routed through module 613 from the pre-processor module 603. If the link is down or slow in responding, then the ESO 
status is set to Z4 to indicate awaiting response from the PROFIT/ATP module 618. Processing on the ESO is halted 

25 until all responses are received from the PROFIT/ATP module 618. The response function module triggers the event 
Z_EDLATP_START (not shown), which starts the ZMOM103 module 61 9. The ZM0M1 03 module 61 9 selects all ESOs 
in status Z4 and analyzes the interface table to see *rf all schedules on the ESO have responses (0 commit is considered 
a valid response) . If the request has all the responses, then control is passed to the ZJDOGJNPUT module 610, 
which calls the post-ATP module 615 to post the ESO to the application. Othenwise, the ESO remains In a Z4 status 

30 until the next triggering of the ZMOM1 03 module 61 9. 

[0062] If processing of the ESO is suspended and a workflow item Is not created, then the Z_IDOC_INPUT module 
61 0 is used to restart the process. This module along with Z_IDOC_MANUALJNPUT moduje 609 which is used in con- 
junction with workflow module 605, is the local IDOC/ALE layer which mimics the corresponding modules in SAP ESOs 
are. currently suspended in 2 cases: 1) if an 860 change order can not be processed because a prior ESO is pending 

35 or the order is blocked, then the status is ZO; 2) if the link to the PROFIT/ATP module 61 8 is not responding in a timely 
fashion, then the status is set to Z4. The ZMOM101 614 and ZMOM103 619 modules use the PROFIT/ATP module 618 
to restart the ESO processing by calling the appropriate function module based upon the status of the ESO. For exam- 
ple, the post-ATP module 61 5 is called if the ESO is in Z4 status, and the pre-processor module 603 is called if the ESO 
is in ZO. This function module Is also responsible for creating workflow items and managing the ESO's status based 

40 upon results from the application function module. 

[0083] The Z_IDOC_INPUT_POST_ATP module 61 5 perfomis four major functions: 1 ) applies the commit informa- 
tion from the PROFIT/ATP rnodule 61 8 back onto the ESO if one or more materials represented in the ESO are on the 
PROFIT/ATP module 61 8; 2) holds the ESO for manual review if key data changes from the PROFIT/ATP module 61 8, 
such as the delivery plant and to split the ESO into multiple ESOs for new order requests if there are multiple line items 

45 on the ESO supplied by more than one delivery plant; 3) calls the appropriate SAP supplied function module to post the 
document (new and change orders, contracts, reference to contracts, and scheduling agreement releases), and 4) per- 
forms post processing logk: based upon the results from the application function module, such as to create spedalized 
work items if the call transaction fails, general cleanup etc. 

[0064] SAP supplies function modules IDOC_INPUT_ORDERS (not shown) to post new sales orders, 
50 IDOCJNPUT_ORDCHG (not shown) to change existing sales order, and IDOC_INPUT_DELINS (not shown) to add 
FDS and JIT scheduling releases. User exits are available at key points in the process to allow local modifications as 
necessary. Several of the user exits are enabled to load additional data Into the BDC session, such as delivery plant, 
delivery blocK and fixed quantity indicator. For delivery schedules, IDOC_INPUT_DELINS (not shown) supports cus- 
tomer expected pricing condition EDI I with screen logic. No edits and audits are performed in these exits. These types 
55 of functions are performed by the pre-processor module 613 and worked in the workbench module 607 before this 
stage. 

[0065] Function modules ZJDOC_INPUT_CONTRACT 616 and ZJDOC_INPUT_REF_CONTRAGT 616 create 
contracts and create an order with reference to the contract, respectively. Both modules are derivatives of 
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IDOC_INPUT_ORDERS 61 Band still share the same user exits. Additional logic was added to support the required 
fields and screen flows. 

[0066] The SAP Supplied Function Modules with User Exits module 616 functions with SAP function modules 
IDOCJNPLrr_ORDERS 616 to post new sales orders, IDOCJNPUT_ORDCHG 616 to change existing sales order, 

5 and ipOC_INPUT_DELINS 616 to add FDS and JIT scheduling releases. User exits are available at key points in the 
process to allow local modifications as necessary. Module 616 enables additional data, such as such as delivery plant, 
delivery block, fixed quantity ind., additional partners, and pricing reference material to be loaded into the BDC session. 
For delivery schedules, IDOC_INPUT_DELINS (not shown) supports customer expected pricing condition EDM with 
screen logic. No edits and audits are perfomned in these exits. These types of functions are performed by pre-processor 

10 module 603 and worked in workbench module 606 before this stage. 

[0067] SAP supplies the Call Trx User Exits (SAPMV45A) module 61 7 to manage the sales order entry set of trans- 
actions, such as create, change and display sales orders, contracts, and scheduling agreements. User exits are also 
available at key processing points to address local processing requirements. Exits were modified to support our unique 
ATP Requirements. 

15 [0088] The following is a description of how the Order Interceptor Rules function. , 
ESQ Audits and Adjustments 

[0069] The following audits and adjustments are performed on the ESO provided the preconditions are satisfied. If 
20 an audit falls or manual review is required, then the ESO is held for con-ection/review in the customer PO workbench 
module 607. The condition must be con-ected or marked reviewed In the customer PO workbench module 607 before 
the ESO can be released to the application for processing. Any time data is changed in the customer PO workbench 
module 607, order interceptor module 603 reapplies the audits. This cycle continues until all messages are corrected 
or marked reviewed. 

25 [0070] All these events occur after the ESO is created on the system and prior to the ESO posting to the applica- 
tion. 

[0071] These audits apply to all ESO types supported by the order interceptor 603. At the present, this includes 
ZORDERS2 for requests processed using VA01 , VA02, and VA41 (Sales Orders and Contracts) transactions and 
ZDELF0R2 for requests processed using transaction VA32 (Scheduling Agreements). 

30 

Validate Logical Message Type 
Preconditjons 

[0072] Audits The following logical message types are supported by the Order interceptor: 

35 ^ 

• ORDERS New OnJer 

• ORDCHG Change Order 

• DELINS Scheduling Agreement 

40 Pseudo-Sales Order Workbench Message 

[0073] Message ZV 327. Logical message type & and message code & not supported by the Order interceptor. The 
ESO must be marked complete in the Workbench and can not be posted to the application. 

45 Validate Entry in Local EDI Configuration Table 
Preconditions 

[0074] None 

50 Audits 

[0075] Ah entry must exist in the table 508 for the given Customer, the ESO's logical message type (edidc-mestyp) 
and message code (edidcnmescod). 

55 Pseudo-sales Order Workbench Message 

[0076] Message Z\/ 222. ZEDITCFG not configured for customer &, logical message type &, and message code &. 
The corresponding entry in ZEDITCFG must be made using trx ZEDI. -> Configuration -> By Customer/Msg/Material 
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before the ESO can be released from the Workbench. 

Validate EIEDS01 Summary Total Segments 
Preconditions 

5 

[0077] Audit is performed if EIEDS01 is provided on the ESO. 

[0078] Audits Verify the following summary segments (E1 EDS01 -SUMID and SUMME) provided on the ESO from 
the EDI Translator match the totals computed by the Order interceptor: 

» 

10 • 001 Total number of line items on the ESO 

• 004 Total requested quantity from delivery schedule segment on the ESO 

• Z01 Total number of segments on the ESO not including summary segments 

Pseudo-Sales Order Worlcbench Message 

[0079] Message ZV 357. Order interceptor detected summary level totals mismatch. The ESO must be marked 
complete in the Workbench and can not be posted to the application. 

Validate External Partner Entries Using EDPAR 
20 Preconditions 

[0080] Audit is perfonned if E1 EDKAI or EIEDPAI is provided on the ESO without field PARTN (LIFNR). 
Audits 

25 

[0081] The following header level partner functions (E1 EDKAI-LIFNR) are cross referenced using EDPAR table to 
determine the SAP internal customer number: 

• AG Sold-To 
30 • LF Supplier 

• AB Unloading Point 

• WE Ship-To 

• SP Carrier 

• RE Bill-To 
35 • RG Payer 

[0082] The following item level partner functions (El EDRW-LIFNR) are cross referenced using SAPs EDPAR table 
to determine the SAP intemal customer number 

40 • WE Ship-To 

• RE Bill-To 

• RG Payer 

Pseudo-Sales Order Workbench Kflessage 

45 

[0083] Message ZV 226: Extemal partner number & invalid for partner function &. The conresponding entry in 
EDPAR must be made using tnc VOED-> Partner -> Application -> Conversion or changing the conresponding LIFNR 
field on the ESO to match EDPAR. The message must be corrected before the ESO can be released from the Work- 
bench. 

50 

Rnd Existing Sales Order 
Preconditions 

[0084] Logical message type ORDCHG. 
55 [0085] The following fields must exist in the ESO: 

• Customer's PO (VBAP-BSTNK) 

• Default Order Type (VBAP-AUART) 
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Audrts 

[0086] Possible candidates are selected from view M_VMVAA using the Customer's Sold-to, PO number, and 
default order type. If no entries are found, or more than I entry found, the ESO is held for the Pseudo-Sales Order Work- 
5 bench. 

Pseudo-sales Order Workbench Message 

[0087] Message ZV 242. Existing sales order not found for customer &, PO number &, and line &. From the Over- 
w view menu, con-ect the customer's PO number. 

[0088] Message ZV 299. Multiple sales orders exist for customer's PO & and line &. Process the error message and 
choose the appropriate sales order for processing. 

[0089] The matching sales order must be detemiined before the ESO can be released from the Workbench. 

15 Split Change ESO into Multiple ESOs 
Preconditions 

[0090] The ESO is split under the following conditions: 

20 ♦ Logical message type ORDCHG 

• Multiple line Items on the ESO 

• Customer's PO and line item are found on separate discrete sales orders 
Audits 

25 

[0091] For each line item on the ESO, the corresponding sales order is found using the Customer's PO and line 
item (VBAP-POSEX). If the line items span multiple sale orders, then the ESO is split into multiple ESOs, one per sales 
order. For example, if line items 1, 3, 4 were found on sales order 0090016323, line items 2,6 were found on 
0090016524, and line item 5 was found on 0090016535, then 3 ESOs would be created. ESO A would contain line 
30 \Xems 1, 3, 4. ESO B would contain line items 2, 6. ESO C would contain line item 5. Each new ESO inherits all the 
header level segments from the original ESO such as partner functions and reference data. The original ESO is marked 
complete (status Z6 - Closed without Posting to Application) after all the ESOs are created successfully. From then on, 
the new ESOs are processed independently from one another. In this example, ESO A could be posted successfully 
where as ESO 8 and C be held for manual review. 

35 

Pseudo-Sales Order Workbench Message See Rhd Existing Sales Order. 
[0092] This is covered under the Rnd Existing Sales Order Module. 

* 

40 Rnd Existing Scheduling Agreement 
Preconditions 

[0093] Logk^al message type DELINS 

[0094] The following fields must exist in the ESO: 

45 

• Customer's material number (VBAP-KDMAT) 

• Optionally, Customer's PO (VBAK-BSTNK) 

Audits 

50 

[0095] Possible candidates are selected from view M_VLPMA using the following selection criteria: 

• KDMAT Customer's material number 

• KUNNR Sold-to 

55 • KNREF Customer's description of partner (plant, storage ♦ location) 

• ABLAD Wildcard + Unloading Point 

• ABRVW Wildcard + delivery schedule usage ID 

• KTEXT Wildcard + search term for product proposal 
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• BSTNK Optionally configured to use Customer PO number (T663A-BSTNKP) 

If no entries are found, or more than I entry found, the ESO is held for the Pseudo-Sales Order Workbench. 
5 Pseudo-Sales Order Workbench Message 

[0096] Message ZV 328. T661 W not configured for vendor &, plant &, and unloading point &. Process the en-or 

message (link to trx OVAI) and make the appropriate entry so that the internal Sold-to can be detennined. 

[0097] Message ZV 329. T663A not configured for sold-to & and unloading point &. Process the en^or message (link 
10 to trx 0VA9) and configure the rules for sold-to and unloading point. 

[0098] Message ZV 330. No scheduling agreement could be found. Process the error message and change the 

selection criteria so that the appropriate scheduling agreement can be chosen. 
^ [0099] Message ZV 331 . No scheduling agreement could be found using customer's PO number. Process the enror 

message and change the selection criteria so that the appropriate scheduling agreement can be chosen. This includes 
15 the customer's PO number. 

[0100] Message ZV 332. No unique scheduling agreement could be detennined. Process the error message and 

select the appropriate scheduling agreement from the list. 

[0101] Message ZV 334. No unique scheduling agreement could be found using customer's PO. Process the en-or 
message and choose the appropriate scheduling agreement from the list. 
20 [0102] Message ZV 361 . Scheduling agreement contains multiple lines for the same customer's material number. 
Process the error message and choose the appropriate line item. 

[0103] Message ZV 363. The Ship-to on ESO does not match the Ship-to on the scheduling agreement. Process 
the error message and change the Ship-to on the ESO. 

[0104] The matching scheduling agreement and line item must be detemnined before the ESO can be released 
25 from the Workbench. 

Required Segments in ESO (ORDERS and ORDCHG) 
Preconditions 

30 [0105] Audit is perfomried for ORDERS and ORDCHG logical messages. 
Audits 

[0106] The following ESO segments are required: 

35 

• E1EDKAI Order Header 

• El EDP01 Line Item (One or more) 

Pseudo-Sales Order Workt>ench Message 

40 

[0107] Message ZV 213. Required segment & not found in ESO. The ESO must be marked complete in the Work- 
bench and can not be posted to the application. 

Required Segments in ESO (DELINS) 

45 

[0108] Preconditions Audit is performed for DELINS logical message. Audits 
[0109] The following ESO segments are required: 

• El EDK09 Release Header 

so • EIEDP10 Line Item (One per ESO) 

• E1EDP16ScheduleJIT/FDSLine 

Pseudo-Sales Order Workbench Message 

55 [0110] Message ZV 21 3. Required segment & notfoundin ESO. The ESO must be marked complete in the Work- 
bench and can not be posted to the appfication. 
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Required Relds in ESO (ORDERS and ORDCHG) 
Preconditions 

[0111] Audit is performed for ORDERS and ORDCHG logical messages. 

5 

Audits 

[0112] The following ESO fields are required: 

10 



Description 


Segment 


Retd 


Notes assigned from 


Customer No 


El EDKAI 


parvw = 'AG' partn (converted from 
lifnr using EDPAR) 


*rf not provided, assigned from edidc- 
sndprn 


Customer's PO No 


EIEDK02 


quaffs 'OOVbelnr 




Customer's Line No 


E1EDP01 


posex 




Customer's Material 


EIEDP19 


qualf= 'GOV if configured for cus- 
tomer's material; qualf='005' if config- 
ured for IBM catalog number 


required If internal material not pro- 
vided qualf= '002' 



Pseudo-Sales Order Workbench Message 

25 

[0113] Message ZV 244. Required field & not supplied in ESO. The ESO must be marked complete in the Wori<- 
bench and can not be posted to the application. 

[0114] Message ZV 340. Determining material (&) not supplied in ESO. The ESO must be marked complete in the 
Woricbench and can not be posted to the application. Optionally, check to see if the local configuration is correct in 
30 ZEDITCFG for this customer and transaction. 

Required Relds in ESO (DELINS) 
Preconditions 

35 [0115] Audit is performed for DELINS logical message. 
Audits 

[0116] The following ESO fields are required: 

40 





Description 


Segment 


Field 


Notes 


45 


Customer No 


EIEDKAI 


parvw = *AG' partn (converted from 
I'rfnr using EDPAR) 


rf not provided, assigned from edidc- 
sndprn 




JIT/FDS Indicator 


EIEDP10 


screl 




50 


Customer's Material 


EIEDP10 


idnkd 


required If internal material not pro- 
vided idnlf 



Pseudo-Sales Order Workbench Message 



[0117] Message ZV 244. Required field & not supplied in ESO. The ESO must be marked complete in the Wort<- 
55 bench and can not be posted to the application. 
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Unique Tracking Number per ESO 
Preconditions 

[0118] Audit is performed rf tracking number is provided in ESO. 

5 

Audits 

[0119] The tracking number is generated from the EDI Translator in E1 EDK02-BELNR and QUALF '202' for tracking 
purposes across the various systems. The tracking number must be unique per ESO. The tracking number is stored in 
10 2EDIACKR-TRACKN0 and can be up to 35 characters in length. 

Pseudo-Sales Order Workbench Message 

[0120] Message ZV 368. Tracking number already assigned to ESO. The ESO must be marked complete in the 
15 Workbench and can not be posted to the application. 

Revision Number In Sequence 

[01 21 ] Preconditions Audit is performed under the following conditions: 

20 

• Revision number provided in the ESO 

• Logical message ORDGHG 

• Local EDI configuration set to process changes in sequence (ZEDITCFG-ZACKPEND) 

• Customer's PO number provided 
25 • Existing Sales Order determined 

Audits 

[0122] The revision number is provided from the EDI Translator in E1 EDK02-BELNR and QUALF 'Z01 '. Its purpose 
30 is to facilitate processing changes from customers in sequence for those customers requiring this feature. The initial 
offering only checks that the revision number is greater than the last revision number processed for this sales docu- 
ment. The audit will be more robust as we understand our trading partner's requirements! The revision number is stored 
in ZEDIACKR-REVISION and can be up to 35 characters in length. 

35 Pseudo-Sales Order Workbench Message 

[0123] Message ZV 358. Change revision level is out of sequence. The ESO must be marked complete in the Work- 
bench and can not be posted to the application. 

40 Determine Order Type 

[01 24] Preconditions Order type is determined under the following conditions: 

• For logical message ORDERS when segment E1 EDK14, qualf *012\ field ORGID is NOT provided on the ESO 
45 • For logical message ORDCHG and DELINS, the existing sales document found 

Audits 

[0125] For new sales order requests, the order type is determined based upon the ESO's logical message type 
50 (edidc-mestyp) and message code (edidc-mescod). If the message type is ORDERS and message code not equal to 

BPO (for blanket PO), then the order type is defaulted to 'OR' for standard order. If the message type is ORDERS and 

message code is BPO, then the order type is defaulted to 'ZBO' for contract. A-er the internal material is determined, 

the default order type can be overridden from the local EDI Configuration table/field ZEDITCFG-ZOVRAUART (rule is 

only applicable at material level). 
55 [0126] For changes to an existing sales document, the order type is taken from the existing document For example, 

a change to an existing standard order would be 'OR' or a change to a scheduling agreement (new release) would be 

'LZ' and so on. 
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Pseudo-Sales Order Workbench Message 

[0127] None 

5 Determine Sales Area 
Preconditions 

[0128] The Sales area is determined under the following conditions: 

10 • For logical message ORDERS when the following segments are NOT provided on the ESO (segment EIEDK14, 
QUALF XXX, field ORGID) Sales Org QUALF '008' 

• Distribution Channel QUALF '007' Division QUALF006* 

• For logical message ORDCHG and DELINS, the existing sales document foundAudrts 

15 [0129] For new sales order requests, the Sales area is determined from table EDSDC. The keys to this table is 
KUNNR (Customer number) and LIFNR (Vendor number sent with EDI). The Customer number is the Sold-to number 
and the Vendor number represents our Sold-to number at the Vendor. LIFNR is taken from the LF partner (E1 EDKAI- 
PARTN) field on the ESO. If this field is not provided, the LIFNR Is taken from the AG partner (EIEDKAI-LIFNR) field on 
the ESO. Together, these fields determine the Sales Area. For changes to an existing sales document, the Sales area 

2o is taken from the existing document 

Pseudo-Sales Order Workbench Message 

[0130] Message ZV 233. Default sales area could not be detemriined for Customer & and Vendor &. Process the 
. 25 error message and make the con-esponding entry in EDSDC using trx VOED-> Partner -> Application -> Cus- 
tomer/Supplier or from the Overview Menu, choose Header -> Partner and change the corresponding LIFNR field on 
the ESO to match EDSDC. The message must be corrected before the ESO can be released from the Workbench. 

Determine Internal Material 

30 

[0131] Preconditions The internal material number is determined under the following conditions: 

• Internal material number NOTprovided and local EDI configuration ZEDITCFG-ZEDIMATNRF = 'R* for redetermine 
material 

35 • Customer's material number provided 

• Sales area determined 

For \og\ca\ message ORDCHG, the sales order must exist (using Customer's PO number). For DELINS (Scheduling 
Agreements), both the Scheduling Agreement and line item must be determined. 

40 

Audits 

[0132] For a new sale order request, or change to an existing order (line item add or change where the Customer's 
material numt)er does not match the Customer's material number on the con-esponding line item (using Customer's line 
45 number), the internal material is detemnined from the Customer Info Record using SAP supplied function module 
RV_CUSTOMER_MATERIAL_ READ. 

[0133] For change to an existing sales document where the Customer's material number does not change, the 
intemal material is taken from the matching line item on the order. 

50 Pseudo-Sales Order Workbench Message 

[0134] Message ZV 289. Customer provided IBM material & on line &. Manual review required. 

Determine Delivering Plant 

55 

[0135] Preconditions The delivering plant is determined under the following conditions: 

• Delivering plant NOT provided 
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• Internal material detemnlned 

• Sales area detemnined 

[0136] For logical message ORDCHG, the sales order must exist (using Customer's PO number). For DELINS 
5 (Scheduling Agreements), both the Scheduling Agreement and line item must be detennined. 

Audits 

[0137] For a new sale order request, or change to an existing order (line item add or change where the Customer's 
10 material number does not match the Customer's material number on the con-esponding line item (using Customer's line 
number), the delivering plant is determined from the material's sales view (table MVECE, field DWERK). For change to 
an existing sales document where the Customer-s material number does not change, the internal material is taken 
from the matching line item on the order. 

75 Pseudo-Sales Order Workbench Message 

[0138] Message ZV 229. Sales view for material & not found. Process the error message and change the Sales 
area or internal material so that the sales view for the material exists. The message must be corrected before the ESC 
can be released from the Workbench. 

20 

Duplicate Sales Order by Line item and IVIaterial 

[01 39] Preconditions Audit is perfomied under the following conditions: 

25 • Logical message ORDERS 

• Customer's PO number provided 

• Customer's line item provided 

• Local EDI configuration set to check for duplicate order (ZEDITCFG-ZEDIBSTNK) 

• Internal material number determined 

30 

Audits 

[0140] Existing sales orders are selected from view M_VMVAA using the Customer's Sold-to, PO number, and 
default order type. I=6r each entry in the view, the corresponding line items are selected from VBAR Each line item on 
35 the ESO is then compared to the entries from VBAR if a match is found, then the ESO Is held for the Pseudo-Sales 
Order Workbench. 

Pseudo-Sales Order Workl:>ench IMessage 

40 [0141] Message ZV 243. Duplicate sales order for customer's PO &, line &,and material. From the Overview Menu, 
change the customer's PO, line, or material rf this is not a duplicate request; othenvise, reject the customer's request. 

Validate Line item and Action Code in Context with Request 
Preconditions 

45 

[0142] Audit is performed under the following condrtions: 

• Customer's line item provided 

• Internal material number detennined for logical message ORDCHG and DELINS 
50 • Existing sales order found for logical message ORDCHG and DELINS 

Audits 

[0143] Each line item on the ESO must be unique. In addition, the following matrix is used to validate the action 
55 code in context with the Customer' s request: 
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Logical Message 


Line Item Action Code 
Domains 


Audit 


ORDERS 


•001 ' - Add 


See Duplicate Sales Order 


ORDCHG andDELINS 


•001* -Add 
'002' - Change 
'003' - Delete 


'001' - Line item and internal material must not exist on sales 
order '002' - Line item and internal material must exist on 
sales order '003' - Line item and internal material must exist 
on sales order 



If any of the audits fail or if a line item '003' delete is requested, then the ESO is held for the Pseudo-Sales Order Work- 
/5 bench 

Pseudo-Sales Order Workbench Message 

[0144] Message ZV 247. Customer's line & not unique on request. Process the error message and change the cus- 
20 tomer's line item to be unique on the ESO if approved by customer; otherwise, reject the customer's request. 

[0145] Message ZV 246. Customer's line & and action code & not valid for an existing order. Process the en'or mes- 
sage and change the action code to a valid domain. 

[0146] Message ZV 245. Customer's line & and action code & not valid for a new sales order. Process the error 
message and change the action code to '001' or reject the custonrier's request. 
25 [0147] Message ZV 275. Customer's line & and action code & inconsistent for an existing sales order. Process the 
error message and change the line item or action code to be consistent or reject the customer's request. 
[0148] Message ZV 283. Customer has requested to delete line &. Manual review required. 

Verify That Ship-to Is Provided on New Sales Order Request 

30 

[0149] Preconditions Audit is performed under the following conditions: 

• Logical message ORDERS 

• Request is NOT a reference to a contract (reference to contract 

35 

provided in El EDK02 '005* or '006* qualifier, field BELNR) 
Audits 

40 [0150] Ship-to party must be provided by the Customer at the header level. The header level partner is found in 
ESO segment EIEDKA2, PARVW ='WE' in field PARTN or LIFNR. If the Ship-to is not provided,then the ESO is held for 
the Pseudo-Sales Order Workbench. 

Pseudo-Sales Order Workbench Message 

45 

[0151 ] Message ZV 226. Extemal partner number & not valid for partner function &. Process the error message and 
choose from the list of EDPAR entries orfastpath to EDPAR maintenance (trx VOED -> Partner -> Application -> Con- 
version. The Ship-to must be provided before the ESO can be released from the Workbench. 

50 Verify ESO In Context as a Sales Document 
Preconditions 

[0152] Audit is performed under the following conditions: 

55 • Sales Area detemnined 

• Internal material determined 

• Delivery plant detemnlned 
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Audits 

[0153] This audit ensures that the combination of key data elements are valid for this request The following audits 
of this nature are performed: 

• Valid Sales Area (VBAP-VKORG, VTWEG, SPAFH*) exists in TVTA 

• Valid Sales Area by Customer (VBAP-VKORG, TVTA-VTWEG, SPAFTT) exists in KNW 

• Internal material exist in material master MARA and not flagged for deletion 

• Internal material exist in sales view MVKE and not flagged for deletion 

• Check for Restricted Material using SAP's supplied function RV_MateriaLStatus_Check 

• Check for Excluded/Listed Material using SAP's supplied function 'Product_Llst_Exclusion' 

• Valid delivering plant for Sales Area (VBAP-VKORG, VTWEG) exists in TVKWZ 

• Internal material exist in delivering plant MARC and not flagged for deletion 

75 Pseudo-Sales Order Workbench Message 

[0154] Message ZV 227. Invalid Sales Area & & &. Process the enror message and enter a valid Sales Area. The 
Sales Area must be valid before the ESO can be released from the Workbench. 

[01 55] Message ZV 378. Sales Area & & & not defined for customer &. Process the error message and enter a valid 
20 Sales Area for customer. The Sales Area must be corrected before the ESO can be released from the Wort<bench. 
[0156] Message ZV 234. Material & not found for flagged for deletion. Process the error message and change the 
material or reject the customer's request. 

[0157] Message ZV 235. Material & Is restricted for use. Process the enror message and change the material or 
reject the customer's request. 

25 [0158] Message ZV 288. Material & has been excluded. Process the error message and change the material or 
reject the customer's request. 

[0159] Message ZV 289. Material & is not listed and therefore, not allowed. Process the error message and change 
the material or reject the customer' s request. 

[0160] Message ZV 231 . Delivering plant & not valid for Sales Area & &. Process the en-or message and change 
30 the delivering plant, sales area or material or reject the customer's request 

Adjust Customer's Dock Date with Transit Time 

[0161 ] Preconditions The offset is performed under the following conditions: 

• No PROFIT/ATP Commits on ESO (Commits present implies ESO is from the OEMLS Interface Logical message 
ORDERS and code 9BD) 

• Customer's line item provided 

• Local EDI configuration set to Customer's dock date (ZEDITCFG-ZEDIDATQAL = 'D') 

• Internal material number detemnined 

• Delivering plant detemnined 

• Ship-to determined Rrstfrom line level on ESO (E1EDPA1) Second from header level on ESO (El EDKAI) Third, if 
logical message ORDCHG or DELINS, then from sales document 

Audits 

[0162] The customer's request dock date is offset the transit time for the Ship-to, delivering plant, and material. The 
transit time number of days is maintained using trx ZED I -> MasteriData -> Transit Time Data. The transit times can be 
maintained (and determined in this order) at the following levels: 

Delivering plant, material. Ship-to 
Delivering plant, Ship-to 
Delivering plant 

55 [0163] Each request date on the ESO is adjusted with the transit time offset. Request date in SAP always repre- 
sents IBM ship date. 
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Adjust Minimum Order Quantity (IVIOQ) and Ship Pacic Quantity (SPQ) 

[0164] Preconditions Adjustment is perfomied under the following conditions: 

5 • Sales Area determined 

• Internal material determined 

• Line item action code NOT = '003' (delete) 

• Schedule lines added to ESO by the Order Interceptor when bringing forward Open JIT schedules are NOT subject 
to MOQ/SPQ checks 

10 

Audits 

[0165] Before MOQ and SPQ checks are performed, the request quantity at the line item level is adjusted to match 
the sum of all the delivery schedule quantities. The minimum order quantity and ship pack quantity for a material is held 
75 at the sales view MVKE, fields AUMNG and SCMG respectively. 

[0166] MOQ checks are carried out at the material level (line items for the same material are summed). If the 
request is out of MOQ, then the following domain values from the local EDI configuration table ZEDITCFG-MOQ deter- 
mines how the quantity is adjusted. This rule can be configured down to the material level: 

20 



Domain Value 


Action 


' ' - Accept as is 


Request quantity NOT adjusted 


'M' - Manual review 


Held for Pseudo-Sales Order Workbench for manual review 


•U' - Round up 


Request quantity for last line item fox material is rounded up to be in MOQ 



SPQ checks are carried out for each schedule line. If the request is out of SPQ, then the following domain values from 
30 the local EDI configuration table ZEDITCFG-SPQ determines, how the quantity is adjusted. This rule can be configured 
down to the material level: 



Domain Value 


Action 


' ' - Accept as is 


Request quantity NOT adjusted 


'M' - Manual review 


Held for Pseudo-Sales Order Workbench for manual review 


'U' - Round up 


Request quantity rounded up to be in SPQ 


'D' - Round down 


Request quantity rounded down to be in SPQ 



Pseudo-Sales Order Workbench Message 

45 

[0167] Message ZV 232. The requested quantity is out of SPQ for line & and schedule &. Process the warning mes- 
sage and change the request quantity to be in SPQ or accept as is. 

[0168] Message ZV 230. The requested quantity is out of MOQ for line &. Process the waning message and 
change the request quantity to be within MOQ or accept as Is. 

50 

Audits Specific by Order Type 
Preconditions 

[0169] None 

55 

Audits 

[0170] The following audits are performed on Rush Orders (SO order type): 
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• If local EDI configuration ZEDITCFG-ZEDIREFBPO is set to true and a reference to a contract is not provided 
(EIEDK02, qualifiers '005* or '006, field BELNR, then manual review is required. 

• If request date < system date, then manual review is required. 

■ 

5 Pseudo-Sales Order Workbench Message 

[0171] Message ZV 366. Rush order requires reference to a contract. Manual review required. 
[0172] Message ZV 392. Request date is in the past. Manual review required. 
[0173] Verify Sales Document is NOT in ATP Pipeline from Prior ESO 

10 

Preconditions 

[0174] Audit is performed under the following conditions: 

• Logical message ORDGHG or DELINS 

• Existing sales order found 

Audits 

[0175] If the request is to change an existing sales document, then a check is made to see if the sales document is 
being processed by PROFIT/ATP (ATP results from prior ESO not applied to order). The ESO to ATP Customer Order 
table ZATPGEN is used for this audit. If an entry is found, then the ESO is held for the Pseudo-Sales Order Workbench. 

Pseudo-Sales Order Workbench Message 

25 [0176] Message ZV 381 . & is being processed by PROFIT/ATP ( ESO &), try again later. 

Validate Logical Message Code for Change Order 

[0177] Preconditions Audit is perfomned under the following conditions: 

30 

• Logical message ORDCHG 
Audits 

35 [0178] The following logical message codes are not supported by the Order interceptor: 

• BPO Change to a Contract 
Pseudo-Sates Order Workbench Message 

40 

[0179] Message ZV 382. Change to a contract is not supported. The ESO must be marked complete in the Work- 
bench and can not be posted to the application. 

Validate if Change is Within Frozen Zone Period 

45 

[0180] Preconditions Audit is performed under the following conditions: 

• Logical message ORDCHG 

• Existing sales order found 

50 • Line item action code indicates change or delete 

Audits 

[0181] If the Customer requests a change to either the date, quantity, or material, then manual review is required. 
55 If the change is occurring within the frozen zone period for the material, then the manual review message will also note 
this condition. The request date and quantity are compared to the order's commit date and quantity if the order is com- 
mitted; othenvise, the request date and quantity are compared to the order's request date and quantity. 
[0182] The frozen zone number of days for a material is defined in the local EDI configuration table ZEDITCFG- 
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ZFROZONE. If the material is not configured, then the frozen zone is taken from the Customer / logical message level 
The change is considered to be within the frozen zone if the requested date < (system date + frozen zone days). 

Pseudo-Sales Order Workbench Message 
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[0183] 

required. 

[0184] 

[0185] 

[0186] 



Message ZV 343. Review changes within frozen zone for & and customer's line item &. Manual review 

Message ZV 351 . Review changes for & and customer's line item &. Manual review required. 

Apply Shipments to Changing a Sales Order 

Preconditions Audit is performed under the following conditions: 
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Logical message ORDCHG 

Existing sales order found 

Line item action code indicates change 



Audits 



[0187] Shipments are applied on the ESO in segment El EDP20 field AMENG and are subsequently available for 
display In the Workbench. In addition, the delta between the request quantity and ship quantity is sent to PROFIT/ATP 
20 for commit (and not the request quantrty). The shipped quantity for a schedule line is derived from tables VBEP- 
WMENG minus VBBE-OMENG (request quantity - open quantity = ship quantity). The following audrts are also per- 
formed: 



25 



30 



35 



40 



• Schedule line still open 

* Requested quantrty from ESO > shipped quantity 
Pseudo-Sales Order Worlcbench Message 

[0188] Message ZV 380. Schedule line is no longer open. The ESO must be marked complete in the Workbench 
and can not be posted to the application. 

[0189] Message ZV 377. Item &: requested quantity & less than delivered quantity &. The ESO must be marked 
complete in the Workbench and can not be posted to the applbation. 

[0190] Message ZV 277. Customer's line item & has been shipped. The request must be applied manually (Order 
interceptor does not support shipment consumption logic with multiple request dates). The ESO must be marked com- 
plete in the Workbench and can not be posted to the application. 

Audits Specific to Create Sales Order with Reference to a Contract 

[0191] Preconditions Audit is performed under the following conditions: 

1 

♦ Logteal message ORDERS 

• Reference to contract provided on ESO ( El EDK02 with qualrfier '005' or 'OOS* field BELN) 



45 



50 



55 



Audits 



0192] The following audits are perfomned when creating a sales order with reference to a contract: 
If reference to contract provided (qualifier '006'), contract must exist 

If reference to contract not provided, then determine contract from referenced contract PO (qualifier '005') using 
view M_VMVAA 

Ship-to is taken from referenced contract if not provided on ESO 
Ship-to on ESO rf provided must match Ship-to on referenced contract 
All materials on ESO are listed on the referenced contract 

If request quantity + prior pulls (using VBFA-RFMNG sales document flow) exceeds open quantrty on contract, then 
manual review required 
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Pseudo-Sales Order Workbench Message 

[0193] Message ZV 364. Contract not found using customer's contract PO. Process the error nnessage and erther 
con-ect the referenced PO or reject the customer's request 
5 [0194] Message ZV 365. No unique contract could be determined using customer's contract PO. Process the error 
message and choose the contract from the list of contracts matching the referenced PO. 

[0195] Message ZV 347. Reference contract & not found for customer &. Process the error message and either cor- 
rect the referenced contract or reject the customer's request. 

[0196] Message ZV 348. Material & not found on referenced contract. Process the eror message and change the 
10 material number or reject the customer's request. 

[0197] Message ZV 371. Ship-to on ESO does not match Ship-to on referenced contract Process the error mes- 
sage and change the Ship-to on the ESO or reject the customer's request. 

[0198] Message ZV 367. Request quantity exceeds open quantity on contract. Manual review required. 

15 Audits Specrfic to Creating a Contract 
Preconditions 

[0199] Audit is perfomned under the following conditions: 

20 • Logical message ORDERS and code BPO 

• Internal material determined 

Audits 

[0200] The following audits are perfomned when creating a contract: 

• Same material can only be on contract one time (no duplicates) 
Pseudo-Sales Order Workbench Message 

[0201] Message ZV 383. Material & not unique on contract request. 

Audits Specific to Creating a Scheduling Agreement Release 
Preconditions 

[0202] Audit is performed under the following conditions: 

• Logical message DELINS 

• Existing Scheduling Agreement found 

• Line item on Scheduling Agreement determined 

• Dates converted from dock to ship date (see Adjust Customer's Dock Date with Transit Time) 
Audit 

45 [0203] The following fields are added to the ESO if not provided: 



50 


Segment-Field 


Description 


Rule 


EIEDK09-LABNK 


Customer's number for fds/jit release 


Generate next number using 








'Number_Get_Nexf , object ZFDSNO or 








ZJITNO, range'OV 




EIEDK09-ABNRA 


Customer's number for previous FDS/JIT 


FromVBLB where ABART=:T for FDS or '2' for 


55 




processed 


JIT and ABRLI = 0 (current version), field 








LABNK 
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If the release is JIT (El EDP1 0-SCREL = '02'), then the following addition audits are perfomned: 

• Verify that an FDS (Forecast Delivery Schedule) exist in table VBLB where ABART = ' V and ABRLI = O 

• If mode is append (El EDP10-I_ABKY = 'V),then any open delivery schedules are brought forward and appended 
5 as delivery schedules on the ESO (segment El EDP16). This audit is perfomned only once. Open schedules are 

determined by comparing tables VBEP and VBBE. If the schedule is still open (entry is VBBE), then the delivery 
schedule is brought forward. In addition, any shipments against the delivery schedule is also applied to the ESO 
(EIEDP1 6-FZABR) and is subsequently available for display in the Workbench. The delta between the request 
quantity and ship quantity is sent to PROFIT/ATP for commit. The shipped quantity for a delivery schedule is 
10 derived from VBEP-WMENG minus VBBE-OMENG. 

The following fields on the ESO are redetermined: 



Segment-Field 


Description 


Rule 


E1EDK10-ABRAB 


Release valid-from date 


Eariies request date (EIEDP1 6-EDATUB)on ESO including those 
brought forward for JIT 


E1EDK10-ABRBI 


Release valid-to date 


Latest request date (E1 EDP1 6-EDATUB) on ESO including those 
brought forward for JIT 


E1EDK10-ABHOR 


JIT valid-to date 


If JIT release, then set to E1 EDK1 0 -ABRBI 



25 Finally the validity periods (valid-from/to dates) are compared to those on the Scheduling Agreement (VBAK-GUEBG 
valid-from and VBAK-GUEEN valid-to). If either of the dates fall outside the horizon, then manual review is required. 

Pseudo-Sales Order Workbench Message 

30 [0204] Message ZV 372. No delivery schedules were provided on the ESO. Reject the Customer's request. 

[0205] Message ZV 369. Valid from date outside the validity period on Scheduling Agreement. Manual review 
required. 

[0206] Message ZV 370. Valid to date outside the validity period on Scheduling Agreement. Manual review 
required. 

35 

Check if Configured for Manual Review 
Preconditions 

[0207] Audit is performed under the following conditions: 

40 

Local EDI configuration set to manual review (ZEDITCFG-ZMANREVIEW = 'V or '3') 
Audits 

45 [0208] The local EDI configuration field ZEDITCFG-ZMANREVIW detemnines if ari ESO is held in the Pseudo- 
Sales Order Workt)ench for manual review. The rule can be configured down to the material level. The domains are: 

• ' ' No manual review required 

• '1 ' Hold for Pseudo-Sales Order Workbench 

50 ♦ ' '2' Block Sates Order and Proposing Acknowledgment 

• '3' Both Hold for Pseudo-Sales Order Workbench and Block Sales Order and Proposing Acknowledgment 

Pseudo-Sales Order Workbench Message 
55 [0209] Message ZV 225. Manual review required. 



26 



EP 1 049 038 A2 

Apply Updates to ESO 
Preconditions 

[0210] The ESO is updated if any updates are made by the Order interceptor. 

5 

Audrts 

[0211] The Order interceptor keeps internal tables of fields and segnnents that need to be updated back on the 

* 

ESO. This includes new segments, changes or deletes to existing segments. The updates are applied to the ESO data 
10 segment in table ESO Data (405)after all the audrts are perfomried and prior to the ESO being passed to subsequent 
processes, such as Pseudo-sales Order Workbench or the Pre and Post ATP processes. Before the updates are 
applied, the original ESO is copied to a new ESO with the status of 70'. Any change to the ESO is noted in the status 
segment ESO Status (406)with a status of '69'. This gives a full audit trait of changes made by the Order interceptor, 
such as if the Sales area, internal material and/or delivering plant.was added, and so on. Table EDSYN Is used during 
15 the update process to ensure proper syntax of the ESO. Function module 2_IDOC_Update Data_Resequence is used 
to perform the actual table update. 

Hold ESO for Pseudo-Sales Order Workbench 
Preconditions 

20 

[0212] The ESO is held in the Pseudo-Sales Order Workbench under the following conditions: 
[021 3] Audit fails or manual review required 

• Header is NOT rejected (If rejected, already in Workbench and ready to release) 

25 

All line items are NOT rejected (If rejected, already in Workbench and ready to release) 

• Input mode is NOT from Pseudo-Sales Order Workbench (Implies already held in Workbench) 
30 Audits 

[0214] Before any audits are perfomried, the Order interceptor builds an internal table of all the error messages that 
have been reviewed in the Pseudo^Sales Order Workbench for the given ESO. Messages are communicated by the 
Order interceptor to the Pseudo-Sales Order Workbench via table ZEDIWMSG. Messages requiring manual review (as 
35 opposed to correction) are flagged as reviewed by the Pseudo-Sales Order Workbench when the appropriate action is 
taken. 

[0215] The Order interceptor records all error and rhanual review messages in an intemal table which is analyzed 
to see if the ESO should be held for the Pseudo-Sales Order Workbench. All entries in the communication table ZEDI- 
WMSG owned by the Order interceptor (some messages are also owned by the Post-ATP and Call Transaction Proc- 

40 esses) are deleted and rebuilt from the internal table. As the entries are added to ZEDIWMSG, the "reviewed" internal 
table is cross-referenced and if a match is found, then the message is flagged as already reviewed. By using this tech- 
nique, the Order interceptor always remembers which messages were reviewed by the User. If the header has been 
rejected, then no messages are recorded in the Workbench. Likewise, messages spedf ic to a line item are not recorded 
if the line item has been rejected. This way, the User can Release the ESO even though an enror condition may still exist 

45 (whbh requires a header or tine level reject). 

[0216] Each entry added to ZEDIWNSG is also added to the ESO's status table ESO Status (406)wrth status of 'Z 
I ' (Message from Order interceptor) provided the message has not already been reviewed. The ESO status is then set 
to •Z2*, held for Pseudo-Sales Order Workbench (unless already *Z2% 

[0217] If the Input Mode is not from the Pseudo-Sales Order Wori<bench (implies Work Item already exists), a 
50 Pseudo-Sales Order Workbench Work Item is created using function module 'Z_Worktlow_En'or_Create' The Work 
Item text consists of order type and action, delivering plant, intemal material, Pseudo-Sales Order and Customer name. 

Reject and Acknowledge ESO without Posting to Application 

55 [0218] Preconditions The ESO is rejected and acknowledged under the following conditions: 

• Header is rejected in the Pseudo-Sales Order Woricbench (segment ZIEDK01, field ZREJCODE non blank) 

• All line items are rejected in the Pseudo-Sales Order Woricbench (segment EIEDP01 , field ABGRU non blank) 
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• Input mode is NOT from Pseudo-Sales Order Workbench (Implies already held in Workbench) 
Audits 

5 [021 9] If the header is rejected or all line items are rejected from the Pseudo-Sales Order Workbench, then an out- 
bound acknowledgment ESO is created using function module 'Z_ACK_REJ_PO'. This EiSO contains the customer's 
original request along with reason codes and description of why the request was rejected. The inbound ESO is then 
marked complete (status set to 'Z6') and not posted to the application. 

10 Pseudo-Sales Order Workbench Message 

[0220] En'or messages from 'Z_AGK_REJ_PO' are recorded for the Pseudo-Sales Order Workbench. 

Pre-ATP Processmg 
15 Preconditions 

[0221 ] The ESO Is sent to Pre-ATP (function module 'Z_IDOCJNPUT_PRE_ATP') under the following conditions: 

• No error or manual review message (unreviewed) exist for ESO 

20 • ESO is not rejected or marked complete or routed to OEMLS (1 11 ) 

• Input method not from Customer PO Workbench (607) 

• Order type defined in table ZATPO Note: No check is made to see if material is an ATP part 
Audits 

25 

[0222] The following functions are perfonmed before the request is sent to ZJDOC_INPUT_PRE_ATP: 

If the logical message is DELINS (Scheduling Agreement) and request is a JIT release, then the open FDS is 
added to the delivery schedule Internal table that Is passed to ATP; likewise, rf the request is a FDS release, then 
the open JIT is added to the delivery schedule intemal table. Notice that these schedules are not applied to the 
ESO. 

Note: PROFIT/ATP requires both the FDS and JIT schedules in order to perform its ATP logic 

[0223] The following structures and internal tables are then constructed from the ESO and existing sales order: 

35 

*■ Header structure XVBAK representing header data on ESO 

• Header structure YVBAK representing header data on existing order 

• Line item table XVBAP representing line items on ESO 

» Line item table YVBAP representing line items on existing order 
40 • Delivery schedule table XVBEP representing deliveries on ESO 

• Delivery schedule table YVBEP representing deliveries on existing order 

• Partner table XVBPA representing partner functions on ESO (both header and line items) 

• Partner table YVBAP representing partner functions on existing order 

• Delivery schedule commit table XVBEP2 representing commits on ESO supplied from external interface such as 
45 OEMLS (111) 

[0224] Extra details: 

• The order number field VBELN in the tables and structures listed above is detemnined as follows: 

50 • For logical message ORDERS and Input Method from the WEB -> "WB + last 8 digits of ESO number 

• For logical message ORDERS and all other Input Methods -> 'ED + last 8 digits of ESO Number 

• For logical message ORDCHG or DELINS -> use existing order number 

• Line items rejected in the Customer PO Workbench (and entire request not rejected) are NOT sent to ATP 

• Line item canceled by Customer are denoted with 'D' in field XVBEP - UPDKZ 
55 • Delivery schedule types are denoted in field XVBEP-ABART 

• ' ' Normal 

• -rFDS 

• '2' JIT 



• 

30 
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• Table ZATPGEN is updated to cross-reference the ESO number wrth the VBELN number sent to ATP. The key val- 
ues are: 

ZATTRIB = 'ZEDIATP* 
5 ZPARAM = Order Number 

ZRECID= 123456 
ZRECVALUE = ESO Number 

[0225] The request is then sent to Pre-ATP (function module Z_IDOC_INPUT_PRE_ATP (313)) which populates 

10 the ATP / SAP Interface table ZATPDEM with the information supplied in the API (see structures and tables above) and 
interfaces to ATP as instructed in the API via MQSeries. Parameter TRIGGER_ATP ('x' send to ATP) controls if the 
request is to be sent to ATP. This is the case for all ESOs except when commits are present on the ESO (from OEMLS 
(1 1 1 ), for example). Parameter RESEND_COMMIT is only used when an ESO is rejected by Customer and the request 
has been committed by ATP and the logical message is ORDGHG or DELINS. When RESEND COMMIT = 'x*, then the 

15 commits on the existing order is resent to ATP to replace the latest commits vs RESEND_COMMIT = * ' which means 
requesting a commit. Parameter TRIGG ER_ZMOM1 03 tells ATP to raise an event to trigger the Restart ESOs in Z4 
Status (ZMOMI03) module (319) upon returning the ATP results. If the link to ATP is not responding in a timely manner 
(currently set to 60 seconds), the Pre-ATP function is re-executed with the trigger set to 'x'. The ESO's status is set to 
'Z4' and processing of the ESO is suspended until the Restart ESOs in Z4 Status (ZMOMI03) module (31 9) is triggered. 

20 [0226] After Pre-ATP is perfomned, the interface table ZATPDEM is polled every 3 seconds to see if the results from 
ATP have been posted. If all delivery schedules on the ESO have a response, then Post-ATP 
(Z_IDOC_INPUT^POST_ATP) is performed. The loop is repeated until all delivery schedules have a response or time 
limit exceeded (up to 20 times or 1 minute elapsed time). If the time limit exceeded, then the Pre-ATP function is re- 
executed with TRIGGER_ZMOMI03 set to Y. When the Restart ESOs in Z4 Status ZMOM1 03 module 31 9 is triggered, 

25 then Post-ATP is performed to pick back up the processing of the ESO. 

Pseudo-sales Order Workbench Message 

[0227] En-or messages from the Z_IDOC_INPUT_PRE_ATP module (313) are recorded for the Customer PO 
30 Workbench module (607). 

Pseudo-Sales Order Workbench Description 

[0228] The Pseudo-Sales Order Workbench 1 06 is a tool to allow the Customer Service Representative (CSR) the 
35 ability to review and/or change a customer's inbound purchase order before it is processed into an SAP Sales Order. 
One of the main advantages is that the customer's order request is presented in a pseudo-sales order. There are cur- 
rently four supported scenarios by the workbench and order interceptor 

1 . Create and changes of SAP Sales Orders (ie, VA01 , VA02) 

40 

Create and changes of SAP Sales Orders with reference to a SAP Contract (ie VA01 , VA02) 
Changes of SAP Scheduling Agreement Outline Agreement (ie, VA32) 
Create SAP Contract Agreement Outline Agreement (i.e., VA41 ) 

45 [0229] There is some initial configuration to be done prior to using the workbench which is not cover in this docu- 
ment such as to configure a specific customer to always manually review their orders, etc. Although, the CSR has the 
capability to branch to selected configuration processes from the workbench which will be covered in detail later in this 
document The order interceptor documentation above explains the customer specific rules and configuration. 
[0230] The CSR can also reject the entire customer order or only reject specific line item(s) of the order. There is 

so also functionality to "accept as is" if the quantities are out of MOQ or SPQ. One of the major functions of the workbench 
is to review and/or correct all of the en'or messages associated with an inbound order. All the corrections will be made 
to the ESO data which is the input to the SAP Sales order create/change processes. Once the data has been changed, 
it must be saved before proceeding to the next screen and/or returning back to the previous screen. The following list 
represents the type of data fields that are allowed to be modified: 

55 

• Sales Area Data 

• Sales Organization, Distribution Channel, Division 
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* Sales Group, Sales Office 

• External Partner Number (ie, ship-to, bill-to, etc) 

• IBM Internal/SAP Material Number 
5 • Delivery Plant 

• Requested Date and Date Fomriat 

• Requested Time 

• Requested Quantity 

• Scheduling Agreement Current & Previous release numbers 
10 • Scheduling Agreement search criteria 

[02311 Other data fields that may be connected due to an en^or will include the customer's PO number, the cus- 
tomer's PO Line Item number, the ESO Action Code for the line item, and others as the workbench grows wrth more 
function. 

15 [0232] Once all en-ors have been corrected/reviewed, you then "Release to Sales Doc" for follow-on processing to 
create/change a SAP Sales Order. If for some reason the SAP Sales Order create/change fails, rt will appear In the 
workbench with a message "Call transaction VA01 failed.... Press HELP(?) for instructions". At that time the CSR should 
following the instruction (s) on how to determine the error causing the transaction to fail. 

[0233] Rgure 6 shows a preferred embodiment of a screen from the workbench to show the "pseudo-sales order" 
20 view. 

Pseudo-Sales Order (Pre-Sales Order) Overview Screen 

[0234] As shown in Figure 7, the customer PO (pre-sales order) overview screen contains all of the header and line 
25 item data from the inbound customer PO. The screen is broken into data groupings to assist the CSR in determining 
the sales area data, and key customer data such as the sold-to customer number, the customer's PO number, the cus- 
tomer PO date, the type of transaction (850 new or 860 change), and the existing SAP Sales Order number. Next are 
all of the items which are scrollable to page down and up. 

[0235] Depending on the error message or if you h'rt the "Overview" pushbotton, certain fields are modifiable. If the 
30 date or quantity on the item level are changed and the inbound ESO had one delivery schedule, the data on the delivery 
schedule would also change. If there were multiple delivery schedules, the item level date and quantity fields will NOT 
be modifiable. 

[0236] If a user chose to reject the entire order, the customer PO (pre-sales order) overview screen is where the 
reject reason code would be entered. 
35 [0237] If PROFIT Commit data is present, the CSR can not change any data due to the dates and quantities are 
already committed for that plant. 
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Overview Menu Fx2Xicl:ion8 



FONCTIOH 


FUNCTIOH DBSCRXPTION 


Save 

■ 


Once you have changed data, 
you have the option of saving 
it on the inbound ESO before 
leaving this screen. If you 
save data on any screen, 
"Data SAVED on ESO 
xxxxxxxxxxxxxxxx" message 
will be received, where the 
x's are the actual ESO 
number . 


Paxtner 


Allows the CSR to view all 
header and item level oartner 
segments of the inbound ESO. 
If needed, changes c£ui be 
made and saved. 


PROFIT Commits 


Allows the CSR to view the 
PROFIT committed dates and 
(quantities as well as the 
requested dates and 
quantities . Anytime PROFIT 
commit data is present on the 
order, no fields are allowed 
to change. 


OBMLS Data 


Allows the CSR to view the 
OEMLS data that was on the 
ESO. This data includes the 
customer PO number, IPR 
number, the IBM supplier 
location code, auid the IBM 
ship to location code. 
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Delivery Schedules 


Allows the CSR to view/ change 
the dates and quantities at 
the delivery schedule level . 
There could be multiple 
delivery schedules per item. 
Other key data is also 
displayed at this level such 
as the MOQ and SPQ quantities 
for that material. You may 
use the checkbox to view that 
specific item's delivery 
schedules or simply hit the 
Delivery Schedules pushbotton 
to page through each one. 


Haterials on EDI Trx 

* 


A popup window displays all 
the material number (s) that 
existed on the inbound EDI 
transaction. It also shows 
what kind of material number 
it is in terms of customer' s 
material number. Vendor's 
material number, 
chamgeable/catalog material 
number, etc. 
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IntoExt Sold -To - config 




• 


data keyed by customer number 


5 




to determine the internal 
customer number from 
external, ISA, or GS numbers 
as well as the specific 


10 


• 

■ 


partner tuncuxon cocie. 
Header Reject Codes - config 
data keyed by reject reason 
code for specific header 


15 


« 


level reject reason 
descriptions 




Salea Order Display 


Allows the CSR to branch to 


20 




native sap sales Order 

tKAiiRrir't' 1 on VAOT t"h^ 

existing Sales Order is 


25 


• 


known, it will automatically 
use that sales order number 




Sctied Agreement: Dlsp 


Allows the CSR to branch to 


30. 




native SAP scheduling 




Agreement Outline Display 
processing via transaction 
VA33 - Xf the existing 


35 




Scheduling Agreement is 


- 


known, it will automatically 
number. 


4Q 


Contract Agrnxnt Dlsp 


Allows the CSR to branch to 

1 

native SAP Contract Agreement 
Outline Display processing 
via transaction VA43. 


45 
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10 



15 




Returns you to the previous 
screen. If you have modified 
any data and have not saved 
it, it will provide you with 
a "Updates Pending" pop -up 
menu asking to "go back and 
SAVE the data?" . You may 
reply YES to return to the 
screen where the changes were 
made for you to issue a SAVE; 
reply NO or CANCEL to return 
to the previous screen 
without saving any data. 



20 



Pseudo-Sales Order (Pre-Sales Order) Delivery Schedules Screen 

25 

[0238] This screen, as shown in Rgure 7, allows the CSR to review/change all the delivery schedules for a line item. 
Both the date and quantity are modifiable fields. If there are multiple delivery schedules, these will be scrollable via the 
page up and page down. Please note that if you change one or more of the delivery schedules, the workbench will auto- 
matically accumulate the total to be updated on the item quantity field. The CSR will be notified via an infomiation mes- 
30 sage if this occurs. This screen also allows the CSR to correct or accept quantities that are out of MOQ or SPQ. Both 
the "SAVE" and "SAVE As Is" works the same way by saving whatever value cun'ently in the quantity field. 

Delivery Schedules Functions 

35 [0239] 



40 


FUNCTION 


FUNCTION DESCRIPTION 


Save of SAVE _As JS 


Once you have changed data, you have the option of saving it on the inbound ESC before 
leaving this screen. If you save data on any screen, you should receive a message "Data 
SAVED on ESQ xxxxxxxxxxxxxxxx", where the x's are the actual ESQ number. 


45 


Next ttem 


If you did not select a single item's delivery schedule to be displayed, the pushbutton will 
page through each line item available (or that contains a delivery schedule) to display the 
delivery schedules data for review/change. 


50 


PROFrr Commits 


Allows the CSR to view the PROFIT committed dates and quantities as well as the 
requested dates and quantities. Anytime PROFIT commit data is present on the order, no 
fields are allowed to change. 




Sales Order Display 


Allows the CSR to branch to native SAP Sales Order Display processing via transaction 
VA03. If the existing Sales Order is known, it will automatically use that sales order 
number. 


55 


Material Master Disp 


Branches to the native SAP Material Master Display transaction MM03. You must select 
the item for which material you want to display via the checkbox. 




Customer Master 
Disp 


Branches to the native SAP Customer Master Display transaction VD03. It will automati- 
cally use the sold-to customer number, and sales area data for the VD03 transaction. 
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(continued) 



FUNCTION 


FUNCTION DESCRIPTION 


Master Sales View 


Branches to the native SAP Materia) Master Display transaction MM03 and chooses the 
sales view data autonnatically. IHere the GSR may see all the sales view data such as 
MOQ SPQ values. 


Dack,Extt,Cancel 


Returns you to the previous screen. If you have modified any data and have not saved It, 
It will provide you with a 'Updates Pending" pop-up menu asking to "go back and SAVE 
the data?". You may reply YES to return to the screen where the changes were made for 
you to issue a SAVE; reply NO or CANCEL to return to the previous screen without saving 
any data. 



Re]ect Acknowledgment Flow and Description 

[0240] The reject acknowledgment process shown in Figure 4 is now explained In greater detail. The reject 
acknowledgment system 107 takes an inbound ESO and creates a corresponding ESO containing reject codes and 
appropriate values. It can be used to reject incoming ESO's w'rth types of sales orders (850), sales order change (860), 
or forecasts (830). 

20 [0241 ] An inbound ESO 401 is rejected from the sales order interceptor workbench by entering a reject code for the 
ESO at a header level. The values that are sent in the reject acknowledgment can be based on the inbound ESO values 
for new sales orders or based on existing data in SAP for rejected change orders. This configuration Is set in table 
2EDITCFG (field ZREJMETHOD). If the outbound ESO is built based on taking the original values, a reject segment 
(Z1EDK01) containing the reject code and description is taken from the edrted ESO and appended to the outbound 

25 reject acknowledgment ESO. The final step is to update the ESO reconciliation table (ZEDIACKR) for the incoming ESO 
with the outbound ESO number. 

[0242] The reject acknowledgment system allows the response to the customer without sending the customer's 
order request to the order processing system. 

[0243] While the invention has been described in terms of a single pretended embodiment, those skilled in the art 
3o will recognize that the invention can be practiced with modification within the spirit and scope of the appended claims. 

Claims 

1 . A system for pre-processing orders before they are transmitted to an order processing system, comprising: 

35 

an order interceptor for receiving and processing electronic sales order data; 

an interface system for receiving the electronic sales order data from the order interceptor and perfomning an 
availability check, wherein the availability check determines the portions of the electrons sales order data that 
can be satisfied; and 

40 means for transmitting at least a portion of the electronic sales order data to the order processing system. 

2. A system according to claim 1 , wherein the order interceptor comprises: 

means for receiving the electronic sales order data; 
45 means for translating the electronic sales order data to an internal fbmnat of the order interceptor; 

means for detemriining if an availability check is required; 
means for transmitting at least a portion of the electronic sales order data; 

means for determining if there are any processing problems associated with the electronic sales order data; 
and 

50 means for processing the electronic sales order data in accordance with business rules. 

3. A system according to claim 1 or 2, further comprising a workbench for receiving electronic sales order data that 
contains errors or is incomplete. 

55 4. A system according to claim 3, wherein the workbench comprises: 

a) means for receiving and displaying electronic sales order data that contains errors or is incomplete; 

b) means for displaying error messages associated with the electronic sales order data of step a); and 
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c) means for correcting, editing, and updating the at least one database containing electronic sales order data. 
5. A system according to claim 4, wherein the workbench further comprises: 

5 means for displaying the status of the electronic sales order data; 

means for determining if configuration rules are satisfied; and 

means for indicating to the order interceptor if at least a portion of the electronic order data is rejected. 

6> A system according to any preceding claim, further comprising a reject acknowledgment system for receiving an 
10 indication from the order interceptor if at least a portion of the electronic sales order data has been rejected. 

7. A system according to claim 6, wherein the reject acknowledgment system comprises: 

means for receiving an indk:ation from the order interceptor that at least a portion of the electronic sales order 
15 data is rejected; and 

means for updating at least one database to indicate the portions of the electronic order data that have been 
rejected. 

8. A system according to claim 7, wherein the reject acknowledgment system further comprises: 

20 

means for determining if the electronic sales order data was received via a transmission from the Worid Wide 
Web; and 

means for updating the at least one database in either an ESO fomnat or an SAP format. 

25 9. A computer implemented method of processing electronic sales order data before it is transmitted to an order 
processing system, comprising the steps of: 

receiving electronic sales order data; 

translating the electronic sales order data to an Intemal fomnat; 
30 transmitting the electronk: sales order data to an interface system, wherein the interface system performs an 

availability check to determine what portion of the electronic sales order data that can be satisfied; and 
if the availability check indteation is to transmit, transmitting the designated portions of the internal format data 
to the order processing system. 

35 10, The computer implemented method of claim 9, further comprising the steps of: 

a) processing the electronic sales order data in accordance with business rules; 

b) determining if there are any processing problems associated with the electronic sales order data; and 

c) if there are processing problenns in step b) , transmitting an electronk; message to at least one user indicat- 
40 ing that the electronic sales order data contains errors or is incomplete. 

11. A computer implemented method according to claim 10. further comprising the steps of: 

enabling a user to correct the electronk: sales order data; and 
45 transmitting the connected electronk: sales order data to the order processing system. 

12. A computer implemented method of daim 9, further comprising the steps of: 

rejelcting the electronic sales order data that cannot be filled; and 
50 updating at least one database to indicate the portions of the electronic order data that have been rejected. 

13. A computer program product comprising: 

a computer usable medium having computer readable program code embodied in the medium for pre-process- 
55 ing orders before they are transmitted to an order processing system, the computer program product having: 

first computer program code for receiving electronic sales order data; 

second computer program code for translating the electronic sales order data to an internal format; 

third computer program code for transmitting the electronic sales order data to an interface system, wherein 
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the interface system performs an availability check to determine the portions of the order interceptor data that 
can be satisfied; and 

fourth computer program code for determining if the availability check indication is to transmit at least a portion 
of the order interceptor data to the order processing system, and, if so, transmitting the designated portions of 
the electronic sales order data to the order processing system. 

14. A computer program product according to daim 13, further having: 

fifth computer program code for processing the electronic sales order data in accordance with business rules; 
sixth computer program code for determining if there are any processing problems associated with the elec- 
tronic sales order data; and 

seventh computer program code for providing an indication to at least one user that the electronic sales order 
data contains errors or is incomplete. 

15. A computer program product according to daim 14 further comprising: 

eighth computer program code for enabling a user to connect the electronic sales order data; and 

ninth computer program code for transmitting the connected electronic sales order data to the order processing 

system. 

s 

16. A computer program product according to daim 15 further comprising: 

tenth computer program code rejecting the electronk^ sales order data that cannot be filled; and 

eleventh computer program code for updating at least one database to indicate the portions of the electrons 

order data that have been rejected. 
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